CI/CD

Definition

Continuous integration means every developer merges to the mainline at least daily, with automated verification on each merge. Continuous delivery means the mainline is always in a releasable state. Continuous deployment means every passing change goes to production automatically.

The distinction matters: delivery is a technical property, deployment is a business choice about whether to exercise it.

Why it is a discipline rather than a toolchain

The value comes from small batches, and the automation exists to make small batches affordable.

A change integrated after three weeks conflicts with everything, is impossible to review meaningfully, and when it breaks something the causal set is enormous. A change integrated after two hours conflicts with little, is reviewable, and when it breaks something the cause is obvious.

A team with an excellent pipeline and long-lived feature branches does not have continuous integration. They have automated builds and the same integration problem.

What a working pipeline requires

• Trunk-based development or very short-lived branches. Feature flags decouple deployment from release, which is what makes merging incomplete work safe.
• A fast pipeline. Beyond about ten minutes for the commit stage, behaviour changes: people batch changes and stop waiting.
• A trustworthy pipeline. A flaky build trains people to re-run rather than investigate, and its signal is then worthless.
• A stop-the-line norm. A red mainline is the team's top priority, or the discipline erodes.
• Automated rollback, so the cost of a bad deployment is minutes rather than a crisis. This is what makes frequent deployment safe rather than reckless.
• Backward-compatible database changes, using expand-and-contract, or the pipeline stops at the schema.

The counter-intuitive result

Deploying more often makes systems more stable, not less — a finding consistently supported by software delivery research. The mechanism is batch size: small changes are easier to review, understand, verify and revert. Large infrequent releases bundle many changes, so when something breaks the cause is ambiguous and rollback is all-or-nothing.

Organisations that deploy rarely "for safety" have optimised for the appearance of control and made each release more dangerous.

Failure scenarios

• Long-lived branches with an excellent pipeline — automation without integration.
• A slow or flaky pipeline, so its signal is ignored.
• Manual approval gates that add days and no information.
• Deployment coupled to release, so nothing can ship until a feature is complete.
• No rollback path, so every deployment is a commitment.

Interview question

"A team has a fully automated pipeline and still releases monthly. What is actually blocking them?"