Deploying more to break less

Why do the teams that release most often have the fewest failed releases?

Take the ordinary intuition about risk. Every release is a chance to break production. So fewer releases means fewer chances, and a team shipping once a quarter should be safer than one shipping forty times a day.

The measured pattern is the opposite. Teams deploying most frequently also have the lowest change failure rates and recover fastest when something does go wrong — the central, repeatedly replicated finding of the DORA research programme, reported across the State of DevOps surveys and in Accelerate (Forsgren, Humble and Kim, 2018). Speed and stability move together rather than trading off.

That should be uncomfortable. Either the intuition is wrong or the measurement is measuring something else. The flaw is real, and it hides in a single word.

The word is "release". The intuition treats a release as a fixed-size unit of risk, so halving the number of releases halves the risk. But a release is not a unit of anything — it is a container, and its contents vary enormously. Ask the obvious follow-up: if a team ships once a quarter instead of daily, what is in the quarterly release? Roughly ninety days of change, all at once.

So the honest comparison is not "one risky event versus ninety". It is "one event carrying ninety changes versus ninety events carrying one change each". Now ask which arrangement is safer, and the intuition stops being obvious.

Consider three things that scale badly with the size of a change set.

First, attribution. If one change goes out and the error rate rises, you know what did it. If ninety go out together and the error rate rises, you have a search problem, and you are conducting it under pressure with users affected. Time to diagnose does not grow linearly with batch size; it grows with the number of plausible interactions, which is much worse.

Second, reversibility. A single change can usually be reverted cleanly. A quarterly release cannot: rolling it back removes eighty-nine things that were fine along with the one that was not, and by then some have written data in a new format. The large batch quietly destroys the cheapest recovery option, which is why its failures last longer as well as being harder to find.

Third, interaction. Defects arising from two changes conflicting cannot occur between changes never in flight together. Batch them and the number of pairs that could interact grows roughly as the square of the batch size. This is what the "fewer chances" intuition misses entirely — it counts events and ignores combinations.

Now notice the loop, because the causation runs both ways and that is what makes the pattern self-reinforcing. A team whose releases hurt becomes cautious. Caution means more approval steps, longer freezes, bigger batches — and bigger batches make the next release hurt more. Fear is not irrational here; it is produced by the very batching that fear caused. Run that cycle for a few years and you get quarterly releases, a change advisory board, and a genuine belief that releasing is dangerous, which is by then true.

The virtuous version runs on the same mechanism. Small releases are usually uneventful, so the team stops treating deployment as an occasion — and because it happens constantly, the deployment path itself is exercised constantly. A path run fifty times a day is debugged; a path run four times a year is only ever run in anger.

One important honesty note about the direction of causation. The DORA data is survey-based and correlational: high frequency and low failure rate travel together, but the deployments do not cause the reliability directly. The plausible common cause is the set of practices that make frequent deployment possible at all — automated testing, trunk-based development, decoupled architecture, one-command rollback. On that reading, deployment frequency is best understood as a symptom you can measure rather than a lever you can simply pull. Mandating daily releases without those underlying capabilities does not produce the outcome, and the research authors say so explicitly.

Three refinements.

First, the claim is about batch size, not calendar frequency. Deploying daily while accumulating a quarter of unreleased features behind a flag is not the same thing, though it is often a useful intermediate step. What reduces risk is that the change per deployment is small; frequency is merely how that shows up on a chart.

Second, "failed release" here means change failure rate — the share of deployments requiring a hotfix, rollback, or patch. Frequent deployers have a lower proportion of failures, and because each covers less change, the impact per failure is smaller too. They do not have fewer incidents in some absolute sense simply by shipping more; the metric is a rate, and reading it as a count is a common error.

Third, and most practically: the safe move is not to deploy more, it is to make deploying cheap and then deploy more because it costs nothing. Reverse that order and you get a team shipping large batches quickly, which is the worst square of the grid. The familiar line — if it hurts, do it more often — is only good advice paired with its implicit second half: do it more often so that you are forced to make it stop hurting.

• How feature flags separate deploying code from releasing behaviour, and the operational debt they create if never removed.
• Why change advisory boards persist despite the evidence that external approval correlates with worse outcomes.

Every term the collection defines is gathered in the glossary.