Library→First Way: Flow→Tools & Techniques→Continuous Integration
Continuous Integration
Every commit triggers an automated build and test run. The foundation of fast feedback and confident deployments.
Video Lesson
A video lesson for this topic is in development. The library articles and mission exercises cover the same material in the meantime.
What is CI?
Continuous Integration is the practice of merging every developer's working copy to a shared mainline multiple times per day, with each integration triggering an automated build and test run. Kent Beck introduced CI as a core practice of Extreme Programming in 1999.
The goal is to detect integration problems early — within minutes of introduction, not weeks later at release time. CI transforms integration from a painful, periodic event into a routine, automated background process.
The CI workflow
The CI cycle is simple and repeatable. Every commit follows the same path:
Every push triggers this cycle automatically. Developers get a pass/fail signal within minutes.
The critical constraint: the entire cycle must complete in under 10 minutes. Developers should be able to commit, push, and see a result before losing context. A 30-minute build is a build developers stop waiting for — and start ignoring.
The three rules of CI
Never break the build
The build is a shared resource. Breaking it blocks every developer. Run tests locally before pushing. Use a pre-push hook if you need discipline.
Fix it fast
When the build breaks, fixing it is the team's highest priority. A broken build is a blocked pipeline. Every minute it stays broken, developers are making decisions without feedback.
Keep the build fast
A slow build is a build no one waits for. 10 minutes is the maximum. Parallelize tests. Remove flaky tests. If it grows beyond 10 minutes, treat it as a bug.
The test pyramid
Mike Cohn's test pyramid describes the right ratio of test types. More tests at the bottom (fast, isolated), fewer at the top (slow, integrated). Inverting the pyramid — many E2E tests, few unit tests — results in a slow, fragile test suite that developers stop trusting.
More unit tests, fewer E2E tests. Fast feedback at the base, slow comprehensive tests at the top.
The Nexus Corp CI pipeline
In Mission 03, you set up GitHub Actions for Nexus Corp. The workflow runs on every push to main:
# .github/workflows/ci.yml
on: push
jobs:
test:
steps:
- run: npm ci
- run: npm test
Before M-03: bugs discovered in production after a month. After M-03: bugs caught within minutes of the commit that introduced them. The feedback loop shrank from weeks to minutes.
Further reading
DevOps Handbook — Chapter 9
Enable and Practice Continuous Integration. The full treatment of CI as an enabling practice for fast flow.
Extreme Programming Explained — Beck
The original source. Chapter 7: Whole Team. CI as a social and technical practice.
DORA State of DevOps Research
CI as a key technical capability predicting software delivery performance.
Continuous Delivery — Humble & Farley
Chapter 3: Continuous Integration. The comprehensive implementation guide.