Continuous Delivery in the Wild

Chapter 4. Deployment and Release

All the participants I surveyed are making production deployments at least daily. In this chapter we’ll look at the techniques they use to achieve this release tempo.

In every single organization, the engineer who makes a change takes ownership of moving that change into production. They are also accountable for ensuring that the change does not cause production defects.

Single-Piece Flow

For smaller codebases owned by a single team, such as microservices, each change landing on master preferably only sits in staging briefly—just long enough for an engineer to make any last spot checks—before being promoted to production by the same engineer.

Several participants shared a strong preference for single-piece flow, a concept from Lean Manufacturing where batch sizes are reduced down to the single item that’s actively being worked on. Teams apply this concept in software by avoiding multiple changes batching up in staging.

Release Buses

A larger, monolithic codebase make it much harder to achieve single piece flow. It has such a broad scope that different teams own different areas (this diffused ownership is, in my mind, a good working definition of a monolith). At any one time, changes will be landing from multiple teams, and they’ll be arriving at a rapid pace, since a large number of engineers are all targeting their changes at the same monolithic codebase.

Organizations handle this scenario by batching production changes up into a release candidate. ...