Recently, there was a very active twitter thread that started when John Cutler asked whether everyone knew about the idea of decoupling deploy and release:
Let’s take three minutes to clear this up because being able to decouple deploy from release is an essential foundation to practicing modern software delivery.
Feel free to watch, read or do both!
First, let’s offer up a straightforward definition of the two terms in the context of “decouple deploy from release”
- Deploy is pushing your code to some part of your infrastructure.
- Release is exposing code to execution, or, put more simply, “turning it on.”
What a Lovely Decouple, and Worth Watching Closely, Too!
When you decouple deploy from release, you can push code to anywhere, even production, without impacting users or your business.
You then can then choose to release it gradually and/or selectively to support internal testing, dogfooding by employees, and progressive rollouts that expose the code to ever-larger numbers of users.
Importantly, if you set things up right, you can also compare the health of system metrics and user behavior between the populations exposed to the new code and those not yet exposed to it.
Release: a Noun or a Verb?
It’s not surprising that there’s a bit of confusion over this idea of decoupling deploy from release.
Historically, we’ve used the term release to represent the bundle of code that is packaged for delivery. The release was then deployed to some infrastructure somewhere.
Bottom line, “release” was used mostly as a noun, as in, “We are building a release” or “We are deploying a release.” When you deployed a release, you were taking it live.
Releasing a Little at a Time
With the advent of continuous deployment pipelines and progressive delivery, we needed to flip the terms around, using “release” as a verb, as in “We’ve released it to internal users only.” Feature flags make that possible by dynamically controlling the extent of exposure, dialing it up or down on a moment’s notice.
Call It What You Want, It’s The Pattern That Matters
It’s possible that new ways to describe this pattern will come along. One suggested solution is to use verbs such as “ramp” that maintain release’s noun-like focus, so you can say, “We have ramped the release to 10% of users.”
In the meantime, the important thing is to learn about the underlying pattern, because it’s an essential foundation for modern software delivery:
This is about decoupling the movement of code around your infrastructure from the exposure of that code to users.
Catch The Decoupled Release Train
Whether you use “release” as a noun or a verb, being able to control (and learn from!) the gradual exposure of code, rather than the high stress of betting your business on “big bang” cutovers, delivers many benefits! We’ll talk more about that in future episodes of Safe at Any Speed.
Jump to the next episode of Safe at Any Speed: Why would I want to decouple deployment from release?
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
Staging environments aren’t great reflections of reality. Instead, investing in CI/CD, feature flags, and QA can skip your code straight to production.
It’s known that modern companies, especially the ones that have adopted agile principles, have achieved a faster degree of delivery cadence, deploy many times per day, diminished the risk of each release, and lowered the time to fix defects in production environments. Feature flags are one of the few key…
Great teams don’t run experiments to prove they are right; they run them to answer questions. Guard against wishful thinking and hidden biases with this shortlist of core principles for productive online controlled experiments. (Video, transcript and screenshots from talk given at Pinterest HQ on September 13, 2019)