Continuous Integration

Fowler's CI definition, the ten practices, and why daily mainline commits with a fast self-testing build is the whole game.

Overview

What continuous integration is

Continuous Integration is the practice of merging every developer's work to a shared mainline at least once a day, with each merge verified by an automated build that includes the test suite. Martin Fowler's canonical 2006 article (martinfowler.com/articles/continuousIntegration.html) defines it: "a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily — leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible."

Why "as quickly as possible" is load-bearing

CI exists because integration in long-lived branches is expensive and unpredictable. The longer two branches diverge, the more painful the eventual merge, and the more likely a defect from weeks ago surfaces only at integration time.

Conflicts — Large, painful merges — Every conflict is small
Regressions — Surface late, hard to attribute — Attributed to a tiny change set
Trunk — Often broken or stale — Always working, always shippable

Origins

The term appears in Grady Booch's 1991 method; Kent Beck and the Extreme Programming community made it a core practice in the late 1990s. Jenkins became the dominant implementation through the 2010s.

GitHub Actions — About 33%
Jenkins — Around 28%
GitLab CI — Around 21%

Fowler's ten practices

1 — Maintain a single source repository
2 — Automate the build
3 — Make the build self-testing
4 — Everyone commits to mainline every day
5 — Every commit should build mainline on an integration machine
6 — Fix broken builds immediately
7 — Keep the build fast
8 — Test in a clone of production
9 — Make it easy for anyone to get the latest executable
10 — Everyone can see what's happening

The three that carry the load

Self-testing build — Without it, "passing CI" means "it linked," roughly worthless
Daily commits to mainline — Not to a feature branch: mainline integration is what makes batches small
Fast feedback — Fowler's rule of thumb is a ten-minute build; past that, developers context-switch and the practice degrades

Key concepts

Continuous Integration (Fowler verbatim): From martinfowler.com/articles/continuousIntegration.html: members of a team integrate their work frequently, usually each person integrates at least daily, leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. The "as quickly as possible" is what makes the practice work.
Mainline / trunk: The single integration branch the team commits to. Usually main. Feature branches are tolerated only if they live hours, not days. PRs that live longer than a day are not "trunk-based development with code review" — they are continuous building of isolated branches, which is the failure mode CI was invented to eliminate.
Self-testing build: A build pipeline that compiles, links, and runs the unit/integration test suite — and fails the build on any test regression. Compilation alone does not count. The test suite must be substantive enough that a green build implies "the system works for the cases the team cares about." Without that implication, "CI passes" carries no information.
Ten-minute build rule: Fowler's heuristic for build duration. Past ten minutes, developers stop waiting on results, start something else, and CI feedback decays toward useless. DORA elite performers report full pipeline lead time under one hour, which is incompatible with hour-long CI builds. Use parallel runners, test sharding, monorepo build systems with remote caches if you have to.
Stop-the-line: Toyota-derived rule (also XP): a red mainline build is the team's top priority. Either it is fixed within ~10 minutes or the offending commit is reverted. Other developers stop pushing until trunk is green. The cultural commitment is what makes CI work — without it, broken-main becomes normalized and signal decays.
Integration machine: A dedicated, reproducible environment that builds every commit. "It works on my machine" is not CI — the integration machine is the source of truth. Hosted runners (GitHub Actions, GitLab CI) are typically used; self-hosted runners are needed for GPU jobs, on-prem dependencies, or scale beyond minute caps.

When to use it

Designing the build/test loop for any new service or repo
Justifying a freeze on long-lived feature branches to leadership
Diagnosing "merge hell" — the symptom is always insufficient integration frequency
Setting realistic targets for build duration and broken-build response time

Interview questions

What is Continuous Integration, and what makes a CI setup actually CI vs theatre?
Why is a fast build (≤10 minutes) such a hard requirement, not a nice-to-have?
How should the team respond when mainline goes red?
Walk through Fowler's ten CI practices and which ones do most of the work.