BOOKS DEEP-READ · CONTINUOUS DELIVERY · CH 15
Continuous Delivery · Ch 15 · Jez Humble & David Farley · 2010
Some apps on your phone update every week; others update twice a year. The difference is usually not how fast the programmers type — it is how that company handles "approved to go live." The first fourteen chapters of Continuous Delivery are all technical: build the automated pipeline, automate the tests, manage the environments. The last chapter turns around and asks a more awkward question: if you already know how to do all that, why is your company still shipping so slowly?
Picture a factory that spent a fortune on a fully automated line, then ruled that every batch needs the plant manager to show up in person and sign a thirty-page form. However fast the line runs, output is capped at the speed of one signature. Plenty of companies live here: the build server runs all day, and a release is still an operation that needs twenty people assembled at 2 a.m. on a Saturday.
A traditional release is like surgery: a hand-written checklist with dozens of steps, carried out by people who don't touch this system day to day, with no clean way back if a step goes wrong. Worse, the roles whose job is "don't let anything break" — ops, security, compliance — are typically only invited at the last minute. The one lever they have left is to make the process heavier: more sign-offs, more documents. So releases get rarer, each one carries more changes, risk goes up, and next time everyone is even more afraid to ship — a knot that tightens on itself.
The first is a ruler. The authors split "how far is this company from continuous delivery" into six separate lines: build, environments and deployment, release and compliance, testing, data, configuration. Each line runs across five levels, from chaos to continuous improvement. Mark yourself honestly on each and you get a jagged profile. The point isn't a high total score — it's to see which line sits furthest left, and fix that one first. Push all six at once and usually none of them moves.
The second is replacing the approval. The most counterintuitive line in the book: if you want auditors satisfied, don't add signatures — add automation. A signature only proves that someone signed. A complete pipeline proves something much harder: the version running in production came from exactly this code change, out of exactly this build, through exactly these tests, released by this person at this time. That ledger is written by machines in the course of ordinary work — nobody can quietly rewrite it.
Don't open with "we'll reach the top level within three years." Find the line that hurts most, move it one notch, check whether the numbers moved, then do the next one. Risk management isn't a thicker document either — it is asking the right questions at the right moments: how do we know this version is done? Who is allowed to deploy? How long does a rollback take? How closely does the test environment resemble production? If you can't answer those, no amount of paperwork helps. And be honest about the cost: this kind of change usually makes a team slower for a while before it pays off — new process, old habits — and teams that can't sit through that stretch tend to abandon it halfway.
What blocks continuous delivery is rarely the technology — it is the question of who dares to approve the release. This chapter's two answers: use a six-line ruler to find your weakest link and move one notch at a time, and swap hand-signed approval for a pipeline that records everything automatically — that is the evidence auditors actually want.
Want the maturity grid, the audit evidence chain, and the head-to-head comparisons? → Switch to the deep read
This is the only chapter in Continuous Delivery that isn't about technology. The first fourteen chapters built the deployment pipeline; this one is about pushing it into a real organization. It delivers three things — a maturity model laid out across six practice areas for locating your weakest link, a project lifecycle that pulls ops and compliance to the very front, and a risk-management approach reduced to a set of concrete questions — plus the book's most counterintuitive claim: when facing auditors, automation is more persuasive than documentation.
This chapter closes Part III, "The Delivery Ecosystem," and the book. It follows the engineering detail of Ch13 (components and dependencies) and Ch14 (version control), and pulls the subject from "how to build it" back to "how to adopt it." It speaks to the most common real-world situation of all: a mid-to-large enterprise that already runs a CI server and automated tests, and still ships once a quarter.
A pipeline is a technical artifact; approval is an organizational decision. Every practice from the first fourteen chapters eventually has to pass through a non-technical gate: who signs off, on what evidence, and who carries the blame. This chapter is about that gap between engineering practice and organizational reality.
What happens if you ignore it? The book names three classic dead ends:
An order-of-magnitude anchor: a traditional enterprise "major release" window is commonly 4–8 hours, 20+ people, scheduled for a Saturday night, with a manual checklist of dozens to hundreds of steps. A team that has done what this book asks deploys in minutes, triggered automatically by a commit, by one person. The gap is two to three orders of magnitude — you cannot close that by asking everyone to be more careful.
What it is: a 6×5 grid. The six practice areas are build management and continuous integration, environments and deployment, release management and compliance, testing, data management, and configuration management. The five levels, low to high, are −1 Regressive (unrepeatable, reactive), 0 Repeatable (documented, partly automated), 1 Consistent (automation across the whole lifecycle), 2 Quantitatively managed (the process is measured and controlled), and 3 Optimizing (the process itself is continuously improved).
The intuition: it isn't one score for the company, it is six separate health checks. Real teams are almost never level across all six — build may already be at level 1 while environments and deployment sit at −1, because production was hand-edited into existence over the years and nobody dares rebuild it.
The mechanism: mark each line honestly, join the dots into a jagged profile, then start with the leftmost line and move exactly one notch.
Why it is designed this way: delivery capability is bounded by the weakest link — however automated your tests, if environments are still assembled by hand your lead time is still measured in days. "One notch at a time" exists so each improvement shows up in the numbers within weeks, instead of becoming a three-year transformation plan. The cost is plain: maturity models invite scoring and ranking, and the book itself warns against it — it is a map for finding your next step, not a report card.
The chapter splits a project into five stages: identification → inception → initiation → develop and release → operation. The real claim isn't the stages themselves but who is in the room when. Traditionally ops, testers, security and DBAs are downstream parties who get handed things; this chapter wants them at the same table from inception, and it wants the deployment pipeline and a production-like environment stood up during initiation — before a single line of business code exists — so that the first end-to-end skeleton reaches production early.
Why: the most expensive rework in delivery almost always comes from environment differences and non-functional requirements (capacity, security, operability). Surface those on release eve and fixing them means changing the architecture; surface them during initiation and it is often a config change. Treating the pipeline as the project's first deliverable is really moving that class of risk from the end of the project to the beginning.
The chapter demystifies risk management: it is not a risk register, it is a set of specific questions put to the delivery team at fixed points. Roughly:
The test is blunt: if these questions can't be answered, or the answers are vague, that is exactly where the risk lives — no thickness of documentation changes the fact. The chapter also traces several common delivery problems back to their root causes (see Table 2); the shared pattern is that symptoms erupt on release day while the causes were planted much earlier.
This is the section most worth remembering, and the most counterintuitive. What auditors actually want is three things: traceability (every artifact in production traces back to a commit and a ticket), no bypass (nobody can put something into production outside the defined process), and reproducibility (environments and configuration can be rebuilt).
The traditional answer supplies all three through documents and signatures — but a signature only proves someone signed. It cannot tell you which build produced the binary now running, and it does not stop someone with access from editing production directly. The pipeline offers something harder: every artifact carries its build number and commit hash, every stage records its pass automatically, and every production deployment leaves "who, when, which artifact." The evidence is a by-product of the machine doing ordinary work, not something reconstructed afterwards.
Segregation of duties isn't abolished here — it is implemented differently. Not "developers may not touch production," but nobody can bypass the pipeline: approval becomes authorization of a specific button on the pipeline, and the person, the time and the target are all recorded. The book's criticism of the CAB lands in the same place: a standing committee approving a batch of unfamiliar changes off a few slides means the approvers have neither the competence nor the information to judge technical risk. That gate buys delay, not safety.
Table 1 · Four release-approval models: who approves, how long, what auditors get, what it costs
| Model | Who approves | Typical lead time | Audit evidence | Fits | Cost |
|---|---|---|---|---|---|
| Manual CAB | A committee, mostly unfamiliar with the system | Days to weeks (wait for the next meeting) | Minutes and sign-off pages; tracing means a human digging | Rare changes, legacy systems, no automation base | Batches grow and so does risk; approvers lack information, so it degrades to rubber-stamping |
| CAB + automated pipeline | Committee approves, pipeline executes | 1–7 days | Full machine trail plus meeting records | Transition period in heavily regulated industries | You get the evidence but not the speed — the gate still lives in a person |
| Peer review + automated gates (the book's position) | A second person on the team plus an all-green pipeline; the production button is authorized | Hours | Commit, build, test, authorization and deployment, end to end | The vast majority of commercial software | Demands a genuinely trustworthy test suite; weak tests mean the gate is fiction |
| Continuous deployment | Nobody — the rules are the gate | Minutes | As above, plus automatic rollback records | Online services that can roll back fast | Needs mature monitoring, canaries and auto-rollback; wrong for software that is hard to update once installed |
Table 2 · Four common delivery problems: symptoms on release day, causes much earlier
| Problem | Symptom | Root cause | First step |
|---|---|---|---|
| Infrequent, buggy releases | Deploys at 2 a.m. on a weekend, 4–8 hours, dozens of checklist steps | No production-like environment; deployment is a human following a list | Script the deployment first, then build one environment from that script |
| Poor application quality | Defects cluster at integration and just before release | Testing isn't in the pipeline; feedback arrives too late | Move the highest-value acceptance tests into the pipeline |
| CI in name only | Trunk is frequently red; a merge costs a week | Long-lived branches and oversized commits | Shorten branch lifetime; fixing red takes priority over new features |
| Poor configuration management | "Works on my machine"; nobody can say where production settings came from | Environment definitions and configuration are not in version control | Put configuration and environment definitions under version control, alongside the code |
When this was written in 2010, most of these claims were assertions distilled from project experience. From 2014 onward, DORA (DevOps Research and Assessment) turned several of them into statistical findings through years of large-scale surveys — a line of work later collected into Accelerate (also covered on this site), which reads as this chapter's empirical sequel.
In today's tooling: the "environment protection rules + required reviewers + deployment history" you see in GitHub Actions, GitLab CI and Argo CD is essentially the industrial form of this chapter's "authorized button plus end-to-end trail." And the evidence form widely accepted in SOC 2 and ISO 27001 audits is exactly the pipeline record, not a hand-filled form.
① In one line: fourteen chapters built the pipeline; this one is about getting it adopted — and the obstacle is usually not technology but "who dares to approve."
② The maturity model is a grid of 6 practice areas × 5 levels (−1 Regressive / 0 Repeatable / 1 Consistent / 2 Quantitatively managed / 3 Optimizing); use it to find the weakest link and move one notch, not to compute a score — capability is bounded by the weakest link.
③ The project lifecycle's point isn't the stages but that ops, test and security are present from inception; the first deliverable of initiation should be the pipeline and a production-like environment.
④ Risk management = specific questions at fixed points (what counts as done, who can deploy, how long a rollback takes, whether environments are scripted). No answer means that is where the risk is.
⑤ The most counterintuitive claim: for auditors, automation beats documentation — the pipeline supplies traceability, no-bypass and reproducibility at once.
⑥ Segregation of duties isn't "developers may not touch production" but nobody can bypass the pipeline; CAB-style meeting approval usually buys delay rather than safety.
⑦ Evidence: years of DORA data show heavyweight change processes fail and elite teams are faster and more stable — but transformation dips first, and improving the process does not automatically improve delivery.