Most people picture "shipping software" as one big release day — a risky, all-hands push once a quarter. Modern teams don't work that way. Code reaches users through an automated pipeline: build, test, scan, stage, canary, production — a sequence of gates that runs on every single change. The gates catch bad changes; the automation removes the human toil. That's how the same pipeline is both fast and safe. Push a change below and watch it flow.
A commit enters on the left and flows to production on the right. Each gate you switch on can stop a bad change before it spreads — but adds a little time. Set your gates, coverage and automation, then push a good change (it should ship clean) or a risky one (it should get caught).
"Continuous" is the word that trips people up. Here's the old model, the three flavours of continuous, and why testing moved from a final phase to a gate on every commit. Tap a card to find it in the table.
The three flavours differ only in who presses the button and how far the automation goes:
Every commit is automatically merged, built and tested against everyone else's work — many times a day. Catches "it broke when we combined it" early, while the change is small.
The pipeline keeps every green build ready to release at any moment — but a human still clicks "deploy". Releasing becomes a routine, rehearsed, one-click decision instead of an event.
No human in the loop: passing the pipeline is the approval. Every green commit ships to production automatically, one small change at a time, behind canaries and health checks.
| Model | Who approves the release | How often | Blast radius of a bad change | Rollback |
|---|---|---|---|---|
| Manual release day | A release manager and a sign-off meeting | Quarterly, on a scheduled "release day" | Huge — a big batch of changes ships at once, so faults are tangled together | Manual and fraught; usually a late-night hotfix scramble |
| Continuous Integration | Automated — every commit is built and tested on merge | Many times a day, into the main branch | Small — problems are caught at integration, before release | Revert the one offending commit; the build goes red immediately |
| Continuous Delivery | Automated up to prod; a human clicks "deploy" | Ready any time; released on demand (often daily) | Small and staged — one release, already validated | One-click and rehearsed; you've practised it |
| Continuous Deployment | No human — passing the pipeline is the approval | Automatically, on every green commit (dozens/day) | Tiny — one change at a time, canaried to a sliver of traffic first | Automatic, on a failed health check, in minutes |
There's no single "right" pipeline — it's a dial between throughput and safety. Build one below (or load a profile), and watch it scored against the four metrics the DORA research uses to separate elite teams from the rest.
The pipeline looks completely different depending on what a mistake costs. Four teams you'd recognise — and what their gates are really buying them.
A product team merges small changes all day. There's no release meeting and no deploy button — a green pipeline ships straight to production, canaried to 1% of traffic first.
Everything is automated — build, test, security scan, staging — but a named human must sign off before code touches a production system handling money. Regulation demands an audit trail.
Something's broken and an on-call engineer, half awake, needs to ship a one-line fix. With a good pipeline the fix runs the exact same gates as any change and canaries out safely.
Move fast, no tests, deploy from a laptop straight to prod. It feels lightning quick — until every release is a coin flip and users become the QA team that finds the breakages.
The gates a team chooses — and the ones it skips — quietly decide whether "just push it out" is a calm sentence or a terrifying one. Getting that design right is where speed and safety stop fighting. That's the work we do with the engineering leaders and teams we coach.
Talk to us about coachingMachines should do the repetitive work — build, test, deploy. Gates should guard the risky moments. Teams that invert it (manual toil, ungated risk) end up both slow and unsafe.
When delivery is a quarterly event, every release is high-stakes. When it's a pipeline that runs constantly, each change is small, caught early, and boring to ship. Boring is the goal.
The old story says pick one. A good pipeline breaks the trade: gates make speed safe, automation makes safety fast. That's why elite teams score high on both at once.