1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

The Difference Between Continuous Delivery and Continuous Deployment

Published by SPK Blog Post
on October 19, 2015

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:

Latest White Papers

Three Trends Are Transforming The Service Desk

Three Trends Are Transforming The Service Desk

Your IT service desk is about to change. Find out what's shaping the future. Three factors — enterprise service management (ESM), collaboration, and intelligent service management — are driving the transformation of the service desk. To better meet customers’ needs...

Related Resources

SPK’s vCAD Solution Increases Productivity, Security, and Savings

SPK’s vCAD Solution Increases Productivity, Security, and Savings

SPK helps a tech manufacturer to increase security and availability of its CAD systems and data by moving them to the cloud—while helping them to save $30k per year.   The Client A well-known maker of power distribution units for IT racks and related equipment...

Accelerating Product Development with Engineering Operations

Accelerating Product Development with Engineering Operations

What is Engineering Operations (EngOps)? Why do you need it, and how do you effectively deploy it?There’s a strange interplay between IT and engineering teams in most firms. That’s because the tech stack that engineers need to design, build, test, and release products...

The problem dispersed design teams face as they scale

The problem dispersed design teams face as they scale

SPK and Associates Co-Founder, Chris McHale, is joined by Cloud and Infrastructure expert, Mike Solinap to talk about engineering productivity in a post-Covid world.  Working remotely, engineering team are challenged by a lack of technology features including...