CI/CD Course
Continuous Integration
In this lesson
Continuous Integration (CI) is the practice of merging every developer's code changes into a shared repository frequently — at least once per day — and automatically verifying each merge with a build and a suite of automated tests. The "continuous" in CI does not mean the process runs without pause; it means there is no deliberate delay between a developer finishing a change and that change being validated against the rest of the codebase. The moment code lands, automation takes over.
CI is the foundation that the rest of CI/CD is built on. Without it, Continuous Delivery and Continuous Deployment are impossible — you cannot reliably deliver software you have not reliably verified. This lesson covers how CI works mechanically, what rules a team must follow to practise it genuinely, and why those rules exist.
The Three Rules of Continuous Integration
CI is not just a tool setting — it is a discipline with three non-negotiable rules. A team that uses GitHub Actions but breaks any of these rules does not have CI. They have scheduled builds.
The Three Rules — and Why Each One Matters
How the Trigger Mechanism Works
The machinery of CI starts with a webhook — a notification that a source code hosting platform (GitHub, GitLab, Bitbucket) sends to a CI server the moment a commit or pull request event occurs. The CI server receives the webhook, checks out the exact commit, spins up a clean environment, and begins executing the pipeline definition.
The key word is clean. Every CI run starts from a fresh, identical environment — no leftover state from a previous run, no files a developer happened to have on their laptop, no manually installed tools. This is what makes CI builds reproducible: the same commit produces the same result every time, on any machine. "It works on my machine" becomes impossible as an excuse because CI's machine is defined precisely in the pipeline file.
The Health Check Analogy
A CI build is like a medical check-up for your code. You do not wait until you feel ill to get checked — you go regularly, and the tests look for problems before symptoms appear. The doctor (the CI server) has a standard protocol (the pipeline), checks the same things every time, and gives you results while the condition is still early-stage and treatable. Waiting months between check-ups means conditions that were minor become serious. Waiting weeks between builds means bugs that were trivial become architectural problems.
What CI Actually Verifies
A CI pipeline does more than compile code and run unit tests. In a mature implementation it verifies the change from multiple angles simultaneously. Understanding what each check is looking for explains why CI catches so many problems that code review alone misses.
What a CI Pipeline Checks — and What It Catches
Trunk-Based Development: The Branching Strategy That Makes CI Work
Trunk-based development is the branching strategy that CI was designed around. Developers work in short-lived feature branches — typically lasting one to two days, never more than a week — and merge directly into the main branch (the "trunk") as soon as the work is complete and CI passes. There are no long-running release branches, no "develop" branches that diverge for months, no feature branches that accumulate weeks of work before merging.
This sounds uncomfortable to teams used to longer-lived branches, but it is the logical consequence of the CI rules above. If every commit must be verified and the build must always be green, then large batches of uncommitted work become a liability — the longer you hold them, the more the rest of the codebase moves and the harder the eventual merge becomes. Trunk-based development turns this into a non-problem by making branches expire before divergence has time to accumulate.
A Healthy CI Day — One Developer's Commits
fix/null-check-user-service. Makes a focused two-line change. Pushes. CI runs in 4 minutes. Green. Merges to main.feat/add-search-filter. Adds the first half of a new feature, behind a feature flag so it is inert in production. CI passes. Merges.feat/search-filter-ui. Completes the UI half of the feature. CI runs — one test fails. Fixes locally in eight minutes. Pushes again. Green. Merges.Keeping the Build Green
The green build is the central contract of CI. When main is green, every developer on the team knows that the codebase compiles, all tests pass, and the code is in a deployable state. It is a shared signal of confidence. When main goes red, that confidence disappears — and every developer currently working off that commit is now building on top of a broken foundation.
This is why the third rule — fix broken builds immediately — is non-negotiable. A broken build is not an individual's problem; it is the whole team's problem. The accepted response is either to fix the issue within minutes or to revert the commit that caused the failure. Reverting is not an admission of defeat — it is the correct action when a fix is not immediately obvious. The build goes green again, work continues, and the fix is developed properly on a branch before being remerged.
< 10 min
Target CI pipeline duration — longer than this and developers stop waiting for results and start bypassing the process
1×/day
Minimum merge frequency for genuine CI — elite teams merge multiple times per day per developer
0 min
Acceptable time for a broken main to remain unfixed — the build queue stops here until green is restored
1–2 days
Maximum lifetime for a feature branch in trunk-based development before it must merge or be abandoned
Warning: A Slow CI Pipeline Will Be Ignored
If a CI pipeline takes 45 minutes to run, developers will not wait for it. They will merge anyway, check the result later, and by the time a failure is reported they will be deep into the next task with no memory of what they changed. The feedback loop that makes CI valuable only works if results arrive while the developer still has the change in their head — which means under 10 minutes. A slow pipeline is not better than no pipeline; it creates false confidence while providing none of the speed benefit.
Key Takeaways from This Lesson
Teacher's Note
The fastest way to see if a team genuinely practises CI: ask how long the oldest open branch is. If the answer is "two weeks" or more, they have scheduled builds — not Continuous Integration.
Practice Questions
Answer in your own words — then check against the expected answer.
1. What is the name for the event notification that a platform like GitHub sends to a CI server the moment a commit or pull request is created, triggering the pipeline to start?
2. What is the name for the branching strategy where developers work in short-lived branches of one to two days and merge directly into the main branch, rather than maintaining long-lived feature branches?
3. When a commit breaks the main build and a fix is not immediately obvious, what is the recommended action to restore the green build while the fix is developed properly?
Lesson Quiz
1. Why does CI eliminate the "it works on my machine" problem that plagued traditional deployment?
2. A team's CI pipeline takes 50 minutes to complete. They argue that a thorough pipeline is better than a fast one. What is the critical problem with this reasoning?
3. A developer merges a commit that breaks the main build. The fix is not obvious and will take at least an hour to investigate. What is the correct response?
Up Next · Lesson 5
Continuous Delivery
CI gets code verified. Continuous Delivery gets it to the door of production — always packaged, always tested, always one click away from going live.