Continuous Delivery

1Release day should not be scary

The book opens on a scene everyone has lived through: the whole team there for an entire weekend, red-eyed in front of a screen at 2 a.m., trying to work out why the deployment is stuck. The authors name three bad habits that lead there.

• Deploying by hand: every step performed by a person, with judgments to make along the way, so human error at every turn.
• Touching a production-like environment only at the very end: the first time operations see the software is release day, and the surprises pour in.
• Configuring production by hand: a setting changed straight on the server, never recorded, impossible to reproduce.

The sentence that sums up their anger: "Releasing software is too often an art; it should be an engineering discipline." Their proof is one anecdote. One of their clients tied up a whole team for seven days, weekends included, for every release, with a poor success rate. After automation, the last release they saw took seven seconds. Nobody noticed a thing, except that the new features were suddenly there. The goal of the book: make releases boring.

2The deployment pipeline, from commit to production

This is the central concept, the one that gives the book its subtitle. An acronym first: CI, continuous integration, is the habit of rebuilding and retesting the application on every change so it stays in working order at all times. The deployment pipeline takes that idea all the way.

Here is how it works. Every change (code, configuration, environment, data) triggers a new instance of the pipeline. First stage, the commit stage: you compile, run the fast unit tests, and build the binaries. If it passes, you get a "release candidate", stored in an artifact repository. Next stage: the automated acceptance tests, which check that the business features work. Then the manual tests and sign-off (UAT, user acceptance testing, validation by representatives of the users). Final stage: release.

The clever part is that the pipeline is a pull system. A tester, an ops engineer or a manager serves themselves: they pick the version they want, the environment they want, and press a button. No more begging a developer for a deployment or waiting for the nightly build. The right metric to judge all this, borrowed from Mary and Tom Poppendieck: "How long would it take your organization to deploy a change that involves just one single line of code?"

3If it hurts, do it more often

This is the master heuristic, the one that runs through the whole book and the easiest to remember. If an activity hurts, do not put it off: do it more often, and right away.

Integrating several developers' code is painful? Integrate on every commit, from day one of the project, instead of piling up for one painful merge at the end. Testing is scary just before release? Test continuously from the start. Documentation is a chore? Write it as you build each feature. The principle has a corollary they call "bring the pain forward": move the effort early in the cycle, where a mistake is cheapest to fix. The authors put it plainly: Extreme Programming (the 2000s agile method that pushes practices like continuous testing and integration to the extreme) already applies this heuristic to development. Their book applies the same one to releasing.

4Build once, deploy the same way everywhere

Two concrete rules that stuck with me, because I live them every day.

The first: build your binaries only once. The binary made at the commit stage is the ONLY one that travels, unchanged, through every environment up to production. Recompiling at each step risks a different compiler or library version, so a binary subtly different from the one you tested. The exact sentence: "The binaries that get deployed into production should be exactly the same as those that went through the acceptance test process." Some pipelines even check the binary's hash at each stage.

The second: deploy the same way everywhere. One deployment script, the same for the developer's machine, staging and production, just parameterized by a config file specific to each environment. The payoff is powerful: the path to production has been tested hundreds of times before the big day. If something breaks in production, you know it is that environment's configuration, never the script. All of this rests on a third principle, simple and radical: everything you need to build, deploy, test and release goes into version control. A new joiner should be able to clone the repository and rebuild everything with a single command.

5"Done" means "released"

How often have you heard a developer say a feature is "done"? For the authors, a feature is only done when it delivers value to users. Not when the code compiles, not when it is "done on my machine". And there is no "80% done": a thing is either done or it is not.

That changes who carries the responsibility. "Done" does not rest on one person: it takes testers, ops and developers working together from start to finish. No more developer throwing code over the wall to testers, who throw it to ops on release day. The whole team owns delivery.

Behind it sits another principle, stolen from the lean movement and W. Edwards Deming: "build quality in". The earlier you catch a defect, the cheaper it is, and the cheapest of all is the one you never let into version control. The direct consequence: testing is not a phase you bolt on after development, it is a continuous activity that belongs to everyone.

6Deploying is not releasing

Here is the chapter I use most, and the least dated in the book. The idea: deploying (putting the binary in place) and releasing (making it visible to users) are two distinct acts. Separating them makes rolling back trivial and defuses the risk of the release.

Three concrete techniques follow.

• Blue-green: two identical production environments, named blue and green. The router sends all traffic to green. You deploy the new version to blue, warm it up, smoke-test it, then flip the router to blue. The switch takes, I quote, "much less than a second". A problem? You flip back to green.
• Canary releasing: you deploy the new version to a handful of servers only, and the router sends just a small fraction of users there. "Like a canary in a coal mine", it surfaces problems fast without touching the majority. If the metrics look good, you widen; if not, you cut.
• Rollback: going back, either by keeping the old version deployed and ready to resume, or by redeploying a known-good version, with the same process tested a hundred times.

One iron rule runs through the chapter: an emergency fix goes through the same pipeline as everything else. Bypassing the pipe "because it is urgent" means shipping something untested into an environment whose state you no longer know.

7Long branches kill integration

This is the book's sharpest stance, the one that still sparks debate. An acronym, well, a term: a branch, in version control, is a parallel copy of the code where you work away from the shared trunk. The authors' verdict: "branching is fundamentally antithetical to continuous integration."

The reasoning is airtight. If everyone works on their own feature branch, then by definition nobody is integrating their work with the others'. You can even run CI on each branch in isolation, it changes nothing: branches drift from the trunk, and merge day brings massive conflicts. Their advice fits in one practice: "Always commit to trunk, and do it at least once a day."

For the big changes that feel too scary to integrate in one go, they offer branch by abstraction (from their colleague Paul Hammant): instead of a branch, you introduce a layer of abstraction in the code and swap the old implementation for the new one little by little, on the trunk, without ever breaking the build. A few branches stay tolerated: the release branch, and the throwaway spike branch.

This idea aged in a curious way. Git was young in 2010, and the authors were wary of it for the enterprise (rewritable history, slipperier audit). Git won everywhere. But their substance, develop on the trunk rather than on long branches, is exactly what the "trunk-based development" movement champions today.

8The database gets versioned too

We talk a lot about deploying code; the book reminds us that data has its own lifecycle and survives deployments and rollbacks. The answer: automate database migrations with versioned scripts, one "roll forward" and one "roll back" script per schema version.

The point is to decouple the schema change from the application deployment. A well-designed migration is compatible with both the old AND the new version of the code, for the duration of the switch. Without that, blue-green and canary fall apart: you cannot flip a router in under a second if the database itself is changing shape. The authors point to Refactoring Databases (Ambler and Sadalage) for the patterns. This is, in 2010 as today, the real hard part of continuous delivery.