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.
Last week, I spoke about the foundational idea of decoupling deployment from release. This week, let’s answer the question, “Why would I want to?” At a high level, there are really just two reasons: #1: You want to prevent code that’s still a work in progress from being exposed to users…
How do you know if your rollouts are going well and should be ramped up or are surfacing issues that need to be fixed before you ramp up? That’s the focus of today’s post and video.
Here’s the video of my talk, “Experimentation for Speed, Safety & Learning in CD” delivered at QCon New York 2019. I’ve edited it down to 39 minutes, so you can easily fit this into a lunch hour or possibly a commute. Text and screenshots follow the video below. Transcript and…