The most important problem that we face as software professionals is
this: If somebody thinks of a good idea, how do we deliver it to users
as quickly as possible? – Continuous Delivery Production is a low-fidelity version of your codebase. Many
deployment metrics are just a highfalutin way to measure the
fidelity of your production. Digital music fidelity gauges the faithfulness of
a digital recording to its analog source. The analog source—a piano,
say—is a continuous signal. The digital copy—an audio CD, an
mp3, or an Ogg—samples that signal at 44.1KHz—a discrete
signal.
Discrete digital sampling of a continuous analog signal
Your main branch is like a soundwave—it carries changes and changes
rapidly—it’s a continuous signal. Your production environment is like an
mp3—it carries forward a single sample until your next deployment—it’s a
discrete signal—it’s a single
SHA1
in the merkle DAG of your main branch.
Discrete production sampling of a continuous stream of commits to the main branch
Everyone at Wikimedia (myself included) devoured Accelerate—it
will frame discussions at the Wikimedia Foundation for years. The theme
of the book is continuous deployment driving organizational change. In the book, however, the authors advocate for tracking both
change lead time and deployment frequency. But I don’t
get the point of measuring both: they’re two ways of looking at the same
thing. If you have a shorter lead time, your deployment frequency is
higher. If your deployment frequency is higher, you have a shorter
change lead time—potato/potato. There are many ways to measure deployment fidelity: the time it takes
for a change in mainline to reach production, the number of deployments
per month, or the number of changes bundled into a deployment. These are
all measures of the speed at which you deliver value to users. Pick
one—not all—to be your North star.
Various metrics gauging deployment fidelity
Continuous deployment is the highest fidelity deployment. High-fidelity audio is lossless, and high-fidelity deployment is
continuous. The best deployments sling out individual production changes
by themselves within minutes of merging to the main branch. This is
continuous deployment, and this is the right way to deploy code.
Continuous deployment is the highest fidelity deployment
Deploying every change individually right when they merge means your
lead time is only limited by your deployment tooling—the fastest it can
be. Your batch size is always 1—the lowest it can be. Your deployment
frequency is Sometimes things aren’t ideal. If your deployment tool cranks out one
change every 10 minutes, you’re capped at 144 changes in a day—if you’re
TheFacebook
then maybe that’s not good enough, and you’re forced to batch changes,
as
Facebook has in the recent past. This is important because “software doesn’t age
like wine; it ages like milk.” Developers can only juggle so many
problems at the same time. If you have a high-fidelity production, then
the picture in the developer’s mind matches production. If not, then
developer assumptions don’t hold. When software languishes undeployed,
developers lose their context and, with it, the ability to solve
production issues caused by their code. The longer the release cycle, the longer the development team has to
make incorrect assumptions before the deployment occurs, and the longer
it will take to fix them – Continuous Delivery Think of the developers. Deploy continuously.
Audio fidelity
Deployment fidelity
Continuous deployment
1*commits—the highest it needs to be.Why deployment fidelity matters
Posted