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