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.

Audio fidelity

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.

Zero-order hold DAC processing

Discrete digital sampling of a continuous analog signal

Deployment fidelity

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.

Zero-order hold deployment

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.

Deployment metrics

Various metrics gauging deployment fidelity

Continuous deployment

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

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 1*commits—the highest it needs to be.

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.

Why deployment fidelity matters

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.