To better support developer and quality assurance personnel, it will be important to understand the characteristics of Continuous Delivery and deployment as well as what makes them unique.

In today’s tech landscape, a wide variety of keywords and acronyms have emerged, and all of this jargon has often made processes and concepts more confusing. For example, in app development, Continuous Delivery and Continuous Deployment are often used interchangeably by organizations, although they are two distinct concepts. The reason for this confusion is because the two subjects are interrelated and work toward the same goal. To better support developer and quality assurance personnel, it will be important to understand the characteristics of Continuous Delivery and deployment as well as what makes them unique.

Defining Continuous Delivery
Agile development environments have turned to Continuous Delivery as a way to get apps out quickly while still upholding the quality that users expect. Once a developer feels that a small batch of code is ready, he or she can send it to the QA team to test and monitor for any potential errors that may emerge. Because the app is essentially being sent piece by piece, QA personnel can quickly go through the code and leverage automated testing for less chance of human error. In addition, the build is sent to a production-like environment to be rigorously evaluated before any changes are released, but the software can be easily deployed once the business is ready to do so.

“Continuous Delivery is about putting the release schedule in the hands of the business, not in the hands of IT,” wrote Continuous Delivery expert Jez Humble in a blog post. “Implementing Continuous Delivery means making sure your software is always production ready throughout its entire life cycle—that any build could potentially be released to users at the touch of a button using a fully automated process in a matter of seconds or minutes.”

The characteristics of Continuous Deployment
The main difference between Continuous Deployment and Continuous Delivery is that deployment takes automation one step further. While Continuous Delivery is left in the hands of the business to release when it feels it’s time, Continuous Deployment automatically does it as soon as the code is ready. So, instead of holding onto the build, it’s directly sent out to all users. In this type of environment, automation will be necessary to ensure that it’s implemented and executed effectively without any cumbersome workflows.

Continuous Deployment also has a certain amount of liability attached to it; after all, what if a critical vulnerability emerges when the app is released? Luckily, Continuous Deployment depends primarily on small changes that are tested through Continuous Delivery. Developers also attach more ownership of the code throughout the software’s life cycle, creating more accountability for the adjustments that are made.

“It sounds risky, but if you have a very extensive and thorough set of automated tests, then the risks are mitigated, especially as the extent of the changes in any one deployment is reduced,” wrote tech journalist Tim Anderson on his blog.

Bridging the gap
As Humble noted, Continuous Deployment implies Continuous Delivery, but the inverse is not true. The main difference between these two concepts is how the builds are ultimately released to the user. For Continuous Delivery, businesses may choose to keep the build and deploy it only when they feel they are ready to do so. In Continuous Delivery, once the app has been tested and declared “done,” it is automatically sent out.

Deciding which will better suit an organization largely depends on its confidence in the code, the magnitude of the change and the immediate need of the patch. However, it also means that the business has planned for every aspect of its demands.

“There are no obstacles to deploying to production,” Humble wrote. “In other words, you could deploy the build to users using a fully automated process at the push of a button if you decided to. In particular, that means you’ve also tested [that] it fulfills its cross-functional characteristics such as capacity, availability and security.”