In my previous article, I define and compare the two software development practices of Continuous Integration and Continuous Delivery. The two practices are complementary and potentially overlapping, but at least their names give us the hint that they are distinct. If presented with the two terms “Continuous Delivery” and “Continuous Deployment” we might be more inclined to wonder if we’re not just hearing synonyms. The truth is, they really are distinct practices and in this article I intend to explain the difference and then focus on what Continuous Deployment is all about.
I described the main objective of Continuous Delivery as “keeping your product in a state where it is always able to deploy into production … if necessary.” To achieve this you are not only validating your code changes through regression and integration testing (as part of a Continuous Integration process), but you’re automating the process of making sure the end result works in a production environment. The act of deploying the final product into real-live-production remains a manual step that can be driven by the needs of the business.
Also, known as “Continuous Release”, Continuous Deployment takes things a step further and automates that transition between “deployable” and “deployed”. At first this might sound like the old quote “It compiles! Ship it!”, but rest assured, it is not. The aforementioned quote is still bad advice and is not what we’re talking about. You absolutely cannot achieve Continuous Deployment without first achieving Continuous Delivery. No developer is going to author a change and then immediately push it into production without running it through the CI and CD pipeline.
If indeed you have achieved Continuous Delivery and you find that you have a steady influx of changes that you’ve proven are “deployable”, then the question is “why not deploy them?” The reality is, you might have a lot of good reasons why you shouldn’t. It’s really cool if you have an automated process that deploys every (QA-approved) change directly into production, but “cool” is not the same as “necessary”. Whether or not the practice of Continuous Deployment is right for your organization is highly dependent on what you’re making and what your end users expect of their interaction with your product.
For the sake of argument, let’s assume there’s nothing stopping you from doing Continuous Deployment—what are the benefits of following this practice? Rapid end user feedback, reduced risk of catastrophic failure through small, incremental changes, the ability to introduce changes gradually in order to ease their adoption, a better relationship with the end user, and generating more value out of each update. Let’s look more closely at these.
The benefits of rapid end user feedback seems fairly straightforward. Feedback regarding a change is likely to happen significantly closer in time to when the change was authored, allowing for better response time in addressing issues because it’s fresh in the developer’s mind.
Introducing smaller changes regularly has a couple benefits. Foremost, having a small delta makes it significantly easier to pinpoint bugs that somehow managed to make it through. It also makes it less disruptive to roll back to the previous version, if that should prove necessary. A more subtle advantage, especially in the area of UX, is the ability to gradually acclimate end users to a changing design. With tongue in cheek I’m going to venture out on a limb and suggest that it’s almost scientific law that any major UI change will be met with at least half of all users declaring the change awful and demanding the old UI back. If, however, we present the user with gradual changes, a la the metaphor of boiling a frog, we are more likely to receive a more tempered response over time.
Through more regular interaction and the perception that “Company X is continually making improvements”, Continuous Deployment can potentially increase your organizations reputation with your end users. Being a consultant, I’ve learned that people are much happier when they have regular updates on your progress. If, by contrast, you show up on the last day of an engagement, hand over your code and say, “Here it all is—should work fine. See ya!” the client may have a few more reservations because they don’t know what in the world you’ve been doing this whole time. In the same way, if your end user is regularly receiving updates or fixes to issues, you’re demonstrating productive activity and the end user is more apt to be gracious when they do find bugs because you’ve proven yourself responsive. While the current software may not be perfect, the user trusts you to be working on it because they’ve seen you working already.
Finally, Continuous Deployment makes it possible to extract the maximum amount of value out of a given piece of software. If we take two generally accepted principles that, 1) Time is money and 2) Software only generates value when it is in production, and put them together, we come to the idea that the only way to get 100% of the value out of any software update is to put it into production the moment it is proven ready.
David Hubbell
Software Engineer
SPK and Associates
Next Steps:
- Contact SPK and Associates to see how we can help your organization with our ALM, PLM, and Engineering Tools Support services.
- Read our White Papers & Case Studies for examples of how SPK leverages technology to advance engineering and business for our clients.
