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.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
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)
Last week we walked The Path To Progressive Delivery. This week, we go deeper. What goals can we meet with the Four Shades of Progressive Delivery? After you read or watch this week’s episode, you will be better equipped to choose a Progressive Delivery approach that works for you. My…
Last week I said I would start a two-part series on progressive delivery. Here’s the promised first installment. Whether you’d rather read or watch the video, let’s jump right in! First “Radical” Idea on the Path to Progressive Delivery: Continuous Integration The story starts with the birth of Continuous Integration.…