Continuous integration

Continuous integration is a working agreement before it is a piece of software. Everyone merges into a single shared branch frequently, and every merge triggers an automated run that builds the project, executes the tests and reports a verdict against that exact commit. The purpose is to keep the distance between any two versions of the codebase small, because the effort of resolving a conflict, and of working out which change broke something, grows with how long people worked apart. Continuous delivery and continuous deployment are built on top of this, and neither is reachable while integration itself is still an event somebody has to schedule.

The commercial argument is about when defects surface rather than whether they do. A failure caught on the commit that caused it comes with an author who still remembers writing it and a diff small enough to read in a minute. The same failure found during a release cycle costs an investigation first and a fix second. Teams that buy the server without adopting the habit end up with long-lived branches and a pipeline reporting on merges that happen twice a month, which is the tooling without any of the benefit.

What a pipeline needs before anyone will trust it

• Speed. If the run takes longer than a coffee break, people stop waiting for the result and start merging on optimism instead.
• Determinism. A pipeline that fails at random teaches an entire team to press retry, and a retry reflex conceals genuine failures perfectly well.
• An unambiguous signal. Red has to mean stop, and a build allowed to sit red for a week has stopped being a gate and become a decoration.
• Isolation between runs. Each execution needs its own data and its own environment, because shared state is where the failures that only appear under parallel execution come from.

A green pipeline is a statement about the tests that exist rather than about the product, and it can only ever fail on questions somebody thought to ask.