Continuous Integration
"Integration" is the act of combining your changes with everyone else's. The continuous part is the whole idea: do it in small doses, constantly, instead of in huge painful batches — and let a machine verify every dose. CI is equal parts workflow habit and automation, and the habit is the half teams get wrong.
💡 The Bottom Line
Merge to the shared branch at least daily, in small pieces. Every push triggers an automated build + test run. The main branch stays green (passing) at all times — and when it goes red, fixing it outranks all other work. That loop is the entire practice.
Why small and often beats big and rare
Merge pain grows faster than linearly with divergence: two branches a day apart merge in seconds; two branches a month apart merge like a hostage negotiation. Integrating daily keeps every conflict tiny and fresh in memory. It also shrinks debugging: when the build breaks, the suspect list is today's handful of small commits, not a quarter's worth of work. "What broke?" becomes a five-minute question.
The machinery around the habit
- A trigger — every push (and every pull request) starts the pipeline automatically. Nobody "remembers to run the tests"; forgetting is impossible.
- A clean environment — the build runs on a fresh runner, not a developer's laptop, catching every "works on my machine" dependency assumption. (Containers, from the Docker track, are how most CI systems provide this.)
- Fast feedback — the run should finish in minutes. Feedback slower than a coffee break gets ignored, and ignored CI is decoration.
- A visible result — green check or red X on the commit/PR, in front of the whole team.
The social contract
The automation only works atop three team agreements: don't push to a red build (you'd be stacking unknowns on unknowns), whoever broke it fixes it now — revert first if the fix isn't obvious — and flaky tests get repaired or deleted, never rerun-until-green. Teams that skip this half end up with a permanently red pipeline everyone ignores, which is worse than no pipeline: it costs money and provides false comfort.
🙋 There Are No Dumb Questions
Q: How do feature branches and pull requests fit in? Isn't a PR "not integrating"?
A: Short-lived branches fit CI fine — the keyword is short. A branch opened Monday
and merged Wednesday, with CI running on the PR the whole time, is continuous integration in
practice. A branch alive for six weeks is not, no matter how much CI runs on it — it's
accumulating divergence the pipeline can't see. Rule of thumb: branches live days, not
weeks.
⚠️ Watch Out
CI verifies only what your tests actually check. A repo with three trivial tests earns the same green checkmark as one with a serious suite — the checkmark means "nothing we looked at broke," and the operative words are we looked at. Growing the test suite is part of practicing CI, not a separate project for later.
🔧 Try It Yourself
Define your project's integration gate as a single command — the one CI will eventually run. For a Node project, for example:
npm ci && npm run lint && npm testRun it from a fresh clone in a clean folder (or a container) — not your working copy. Anything that fails there but passes on your machine is a hidden dependency CI would have caught. That command becomes the heart of your pipeline in the next lesson — and of the GitHub Actions track after that.
✅ Quick Check
The main branch's build goes red. What does CI practice say happens next?
Next up: giving the automation a shape — pipelines and stages, from "commit lands" to "artifact ready to deploy."