One of the discussions I keep on having is how practices like Continuous Delivery can jeopardise quality, not allowing enough time for “proper testing”. If every code change can be deployed to production how can we possibly know if the end user experience will remain good?
A technique for maintaining a certain level of quality is to separate the notion of “technically ready” vs “user ready” by decoupling code shipped to production from code being accessible to the users. Unfortunately, I still find that this technique or its usage is not common knowledge. In the post below I tried to gather some quotes from people that can explain this topic much better than I could ever do.
Starting with a definition
I find it very helpful to start with some terminology, to get everyone on the same page. When it comes to deployments and releases, I subscribe to this one by ThoughtWorks from 2016.
We recommend strictly using the term Deployment when referring to the act of deploying a change to application components or infrastructure. The term Release should be used when a feature change is released to end users, with a business impact.
ThoughtWorks Technology Radar 2016
“But, the Continuous Delivery book says “always in a releasable state”“
The book was published in 2010 and my assumption is that back then the terms releasable and deployable had more chances of being the same thing. Nevertheless, that doesn’t mean that the authors don’t know that there is a difference between the two concepts.
“But, even a technical change can cause problems to the end users”
Indeed, even though the smaller the change the smaller the chances of causing an issue, that doesn’t mean that we shouldn’t put mechanisms in place to be able to understand how our changes affect the system. That’s where Observability comes into play.
“But, does the Testing community know about the distinction?”
Yes, testers working in Cloud native products that have embraced DevOps principles, know that different types of testing are needed for when the product is in a deployable state and for when it is customer ready.
Human-centric testing, whether tests the team hasn’t automated yet or testing activities like exploratory and accessibility testing, is as much a part of a delivery pipeline as automated tests.
The key is recognizing the difference between deploying and releasing.
Agile Testing Condensed: A Brief Introduction (2019) by Janet Gregory & Lisa Crispin
“But, does the Product community know about the distinction?”
The product community loves anything that enables them to set up good experiments. No wonder they see the possibility to test new features to a targeted, smaller audience as a plus.
“But, are decoupled deployments and releases enough for a successful product?”
Deploying often is the gateway to having a stable product, where you can change things easily. Nevertheless, releasing functionality to your customers is the only way to assess the real value of your product. Aiming to even make small changes available is good way for getting the necessary feedback.
Decoupling deployments and releases does not by default reduce the amount of work needed to have a product of good quality. We need reliable deployment pipelines and meaningful code instrumentation to uphold the quality of code changes. We also need meaningful activities before releasing to our customers like Behaviour Driven Development (BDD) (you can find more ideas in my older post Some Ideas for Reducing “Release Decision” Time). But, by having our code in a deployable state, even if it is not necessarily in a releasable state, we avoid having a work overload before making a release decision for our customers. And with less load, chances are that we take better quality decisions.
More Questions Than Answers 
One thought on “Decoupling Deployments from Releases: in Other People’s Words”