Chapter 12. Automated Deployment
and Continuous Delivery
12.1. Introduction
Continuous Integration should not stop once your application compiles correctly. Nor should it stop once
you can run a set of automated tests or automatically check and audit the code for potential quality issues.
The next logical step, once you have achieved all of these, is to extend your build automation process
to the deployment phase. This practice is globally known as Automated Deployment or Continuous
Deployment.
In its most advanced form, Continuous Deployment is the process whereby any code change, subject
to automated tests and other appropriate verifications, is immediately deployed into production. The
aim is to reduce cycle time and reduce the time and effort involved in the deployment process. This in
turn helps development teams reduce the time taken to deliver individual features or bug fixes, and as
a consequence significantly increase their throughput. Reducing or eliminating the periods of intense
activity leading up to a traditional release and deployment also frees up time and resources for process
improvement and innovation. This approach is comparable to the philosophy of continual improvement
promoted by lean processes such as Kanban.
Systematically deploying the latest code into production is not always suitable, however, no matter how
good your automated tests are. Many organizations are not well prepared for new versions appearing
unannounced every week; users might need to be trained, products may need to be marketed, and so
forth. A more conservative variation on this theme, often seen in larger organizations, is to have the entire
deployment process automated but to trigger the actual deployment manually in a one-click process.
This is known as Continuous Delivery, and it has all the advantages of Continuous Deployment without
the disadvantages. Variations on Continuous Delivery may also involve automatically deploying code
to certain environments (such as test and QA) while using a manual one-click deployment for the
other environments (such as UAT and Production). The most important distinguishing characteristic of
Continuous Delivery is that any and every successful build that has passed all the relevant automated
tests and quality gates can potentially be deployed into production via a fully automated one-click
process and be in the hands of the end-user within minutes. However, the process is not automatic: it is
the business, rather than IT, that decides the best time to deliver the latest changes.
Both Continuous Deployment and Continuous Delivery are rightly considered to represent a very high
level of maturity in terms of build automation and SDLC practices. These techniques cannot exist
without an extremely solid set of automated tests. Nor can they exist without a CI environment and
a robust built pipeline—indeed it typically represents the final stage and goal of the build pipeline.
However, considering the significant advantages that Continuous Deployment/Delivery can bring to an
organization, it is a worthy goal. During the remainder of this chapter, we will use the general term of
“Continuous Deployment” to refer to both Continuous Deployment and Continuous Delivery. Indeed,