CI/CD Lesson 11 – Source Code Management | Dataplexa

CI/CD Course

I. CI/CD Fundamentals
1. What is CI/CD 2. Software Development Lifecycle 3. Problems with Traditional Deployment 4. Continuous Integration 5. Continuous Delivery 6. Continuous Deployment 7. CI vs CD 8. CI/CD Pipeline Overview 9. Benefits of CI/CD 10. CI/CD in Modern DevOps
II. CI/CD Pipeline Concepts
11. Source Code Management 12. Build Automation 13. Dependency Management 14. Artifact Management 15. Automated Testing 16. Test Types in Pipelines 17. Code Quality & Static Analysis 18. CI/CD Pipeline Stages 19. Environment Promotion 20. Rollback Strategies
III. CI/CD Architecture & Security
21. CI/CD Architecture Design 22. Pipeline as Code 23. Secrets Management 24. Environment Variables & Configs 25. Secure CI/CD Pipelines 26. Access Control & Permissions 27. CI/CD with Containers 28. CI/CD with Docker 29. CI/CD with Kubernetes 30. Monitoring CI/CD Pipelines
IV. Enterprise CI/CD & Real-World
31. CI/CD for Microservices 32. CI/CD for Monolithic Applications 33. Blue-Green Deployments 34. Canary Deployments 35. Feature Flags 36. Infrastructure as Code in CI/CD 37. CI/CD in Cloud Environments 38. CI/CD Best Practices 39. CI/CD Anti-Patterns 40. Mini Project
Section II · Lesson 11

Source Code Management

In this lesson

What SCM Is Branching Strategies Pull Request Workflow Trunk-Based Development SCM & the Pipeline

Source Code Management (SCM) is the practice of tracking, versioning, and coordinating changes to a codebase across a team of developers. It is the layer beneath every CI/CD pipeline — the place where code lives, where changes are proposed, reviewed, and merged, and where the events that trigger pipeline runs originate. Without a structured SCM practice, there is no stable foundation for CI/CD to build on: you cannot automate what you cannot reliably version.

Git as the Trigger — How SCM Starts the Pipeline

In a GitHub Actions pipeline, almost every workflow starts with a Git event. A developer pushes a commit, opens a pull request, or merges to the main branch — and the CI/CD platform responds by running a defined set of jobs. The pipeline is not a separate system that happens to use Git; it is an event listener attached to a Git repository.

This means your branching strategy is not just a version control decision — it is a pipeline architecture decision. Different branching models produce different pipeline trigger patterns, different feedback loops, and different integration risks. The three most common models in CI/CD contexts are feature branch workflows, Gitflow, and trunk-based development.

The Air Traffic Control Analogy

A Git repository is like an airport, and every branch is a runway. Air traffic control — your branching strategy — decides which planes land where, in what order, and how long they queue before they can merge onto the main taxiway. A well-designed branching model keeps traffic flowing smoothly. A poorly designed one creates delays, near-misses, and the occasional collision — which in code terms means a merge conflict that takes a morning to resolve and a regression that slips through because nobody was sure which version was the reference.

Branching Strategies — How the Three Models Compare

Each branching strategy makes different trade-offs between isolation, integration frequency, and deployment complexity. The model you choose directly shapes how your pipeline is structured.

Branching Strategy Comparison

Feature Branch
Gitflow
Trunk-Based
Integration
On merge, often days apart
On release, often weeks apart
Continuously, multiple times per day
CI Trigger
On PR open and merge
On merge to develop or release branch
On every commit to main
Merge Risk
Medium — branches diverge over days
High — long-lived branches accumulate drift
Low — changes are small and integrated immediately
Deploy Freq.
Daily to weekly
Weekly to monthly
Multiple times per day
Best for
Small-to-medium teams, most common default
Libraries, versioned products with parallel support
High-performance teams with strong test coverage

The Pull Request — Where Quality Control Happens

In a CI/CD workflow, the pull request (or merge request in GitLab terminology) is not just a code review tool — it is the primary quality gate before code reaches the main branch. Every PR is an opportunity to run the full CI pipeline against the proposed change before it is integrated, not after.

A well-structured PR workflow in a CI/CD context does several things automatically. The CI pipeline runs against the PR branch the moment it is opened. Status checks must pass before a merge is allowed. Required reviewers must approve. Branch protection rules prevent anyone — including repository administrators — from bypassing these checks. The result is a main branch that is always in a deployable state, because nothing reaches it that has not passed the full suite.

What a PR Triggers in a Mature CI/CD Pipeline

🔨
Build verification
The code compiles or the application builds successfully against the proposed change. Catches syntax errors, missing dependencies, and broken imports before any human reviewer looks at the code.
🧪
Automated test suite
Unit tests, integration tests, and any other automated checks run against the PR branch. A single failing test blocks the merge. Covered in depth in Lessons 15 and 16.
🔍
Static analysis and linting
Code style, complexity metrics, and potential bug patterns are checked automatically. Reviewers spend their time on logic and design, not formatting. Covered in Lesson 17.
🔒
Security scanning
Dependency vulnerability checks and secret detection run on every PR. A hardcoded API key or a known CVE in a new dependency is caught before it is ever merged. Covered in Lesson 25.

Trunk-Based Development — Why High-Performing Teams Prefer It

Trunk-based development is the branching strategy most strongly correlated with high deployment frequency in DORA research. Instead of working in long-lived feature branches, developers commit directly to the main branch (the "trunk") — or work in very short-lived branches that are merged within a day. The result is a codebase that is always integrated, always tested, and always in a deployable state.

The concern most teams raise about trunk-based development is: "What if a feature is not finished when we deploy?" The answer is feature flags — the ability to deploy code to production while keeping the feature hidden from users until it is ready. This decoupling of deployment from release is what makes trunk-based development practical. You will see this in detail in Lesson 35, but it is worth knowing now that trunk-based development and feature flags are almost always used together.

The pipeline advantage is significant. With trunk-based development, the CI pipeline runs on every single commit to main. There is no "integration branch" that accumulates changes over weeks and then causes a painful merge. The feedback loop is as tight as it can be — every change is verified immediately, in context, against the current state of the codebase.

A Single Commit — From Push to Production (Trunk-Based)

0:00
Developer pushes a small, focused commit to a short-lived branch. The commit fixes a single bug and touches three files.
0:01
GitHub Actions triggers automatically. Build starts. The developer opens a PR and adds a short description.
0:04
All 612 tests pass. Static analysis clean. No security flags. PR status checks turn green. A reviewer is auto-assigned.
0:18
Reviewer approves. Developer merges. The branch is deleted automatically. The merge triggers the deploy pipeline.
0:26
Code is running in production. Total elapsed time: 26 minutes. No release call. No deployment window. No waiting.

Branch Protection and Repository Structure

A CI/CD pipeline is only as reliable as the branch it runs on. Branch protection rules are the guardrails that prevent code from bypassing the pipeline and landing directly in the main branch. They are configured at the repository level, not in the pipeline itself.

In GitHub, branch protection rules for a CI/CD-enabled repository typically include: requiring CI status checks to pass before merging, requiring at least one reviewer approval, disabling force pushes to protected branches, and requiring branches to be up to date with main before they can be merged. Together, these rules ensure the pipeline is not a suggestion — it is a hard gate that every change must pass through.

Branch Protection Settings — What Each One Does

Require status checks to pass
The CI pipeline must report success before the merge button is enabled. The most important protection in any CI/CD setup.
Require pull request reviews
At least one (usually two) approved reviews required. Prevents solo merges and ensures a second pair of eyes on every change.
Require branch to be up to date
The PR branch must include all commits from main before merging. Prevents a green CI run on stale code that conflicts with recent changes.
Restrict who can push to branch
Direct pushes to main are blocked for everyone except designated roles. Commits must come through a PR.
Disallow force pushes
Prevents rewriting the history of a protected branch. Critical for maintaining audit trails and pipeline reproducibility.

SCM and the Pipeline — Events, Triggers, and the Main Branch

Everything the pipeline does flows from a single commitment: the main branch is always deployable. SCM practices — branching strategy, PR gates, branch protection — are the mechanisms that uphold that commitment. The pipeline enforces it technically; the SCM workflow is what makes it structurally possible.

In GitHub Actions, pipeline triggers are defined in the workflow file using the on: key. The most common SCM events used as triggers are push to a branch, pull_request opened or updated, and merge to main. Each maps to a different point in the development workflow and a different purpose in the pipeline — a PR trigger runs CI checks to gate the merge; a push-to-main trigger kicks off the deployment pipeline. The two are complementary, not interchangeable.

SCM Events and Their Pipeline Purpose

on: pull_request
Triggers on PR open, update, or reopen. Runs the CI suite — build, test, lint, scan — to verify the change before it can be merged. This is the quality gate. A failure here blocks the merge.
on: push (main)
Triggers after a PR is merged to main. Runs the deployment pipeline — build the release artifact, deploy to staging, promote to production. This is the delivery trigger.
on: push (branch)
Triggers on any push to a feature branch. Used to run a faster subset of CI — often just the build and unit tests — so developers get early feedback without waiting for a full PR run.
on: schedule
Triggers on a cron schedule regardless of commits. Used for nightly integration tests, dependency audits, or security scans that are too slow to run on every PR.

Warning: Long-Lived Feature Branches Are Integration Risk Accumulating in Silence

The longer a branch lives without being merged, the more it diverges from the rest of the codebase — and the larger, riskier, and harder to review the eventual merge becomes. A branch that has been active for two weeks is not twice as risky as a one-week branch; it is often ten times as risky, because the conflicts are non-linear. The industry term for this is "merge hell," and it is one of the primary conditions that CI/CD is designed to prevent. If your branches routinely live for more than two or three days, your branching model is working against your pipeline, not with it.

Key Takeaways from This Lesson

✓
SCM is the foundation of every pipeline — Git events (push, PR, merge) are what trigger CI/CD runs. Without structured version control, there is no stable base for automation to operate on.
✓
Branching strategy is a pipeline architecture decision — different models produce different trigger patterns, integration frequencies, and merge risk profiles. The model shapes the pipeline as much as the pipeline shapes the model.
✓
Pull requests are quality gates, not just review tools — a PR triggers the full build, test, analysis, and security scan pipeline before any human reviews the code.
✓
Trunk-based development is the high-performance default — short-lived branches merged daily keep integration risk near zero and the feedback loop as tight as it can be.
✓
Branch protection rules make the pipeline non-optional — requiring CI checks to pass and disabling direct pushes to main turns the pipeline from a suggestion into a hard gate every change must pass through.

Teacher's Note

If you want a single number to track SCM health, track average branch age — the time between a branch being created and being merged. If it is creeping above two days, your integration risk is growing faster than your test suite can catch it.

Practice Questions

Answer in your own words — then check against the expected answer.

1. What is the branching strategy — most strongly correlated with high deployment frequency in DORA research — where developers commit to the main branch directly or via branches that live for less than a day?



2. What is the name of the repository-level settings — configured in GitHub — that require CI status checks to pass and prevent direct pushes to the main branch, making the pipeline a hard gate rather than an optional step?



3. What technique allows trunk-based development teams to deploy unfinished features to production safely — by shipping the code while keeping the feature hidden from users until it is ready?



Lesson Quiz

1. Why does the choice of branching strategy directly affect how well a CI/CD pipeline performs?


2. A team wants to deploy to production multiple times per day. Which branching strategy is the worst fit for this goal, and why?


3. Of all the branch protection settings available in GitHub, which one is the most critical for a CI/CD workflow and why?


Up Next · Lesson 12

Build Automation

Code merged — now what? Build automation is the first stage the pipeline runs after a merge: compiling, packaging, and producing a consistent, reproducible artifact from every commit.

← Previous Course Index Next →