Continuous integration made integration a non-issue and brought us to the point where we always have a set of working and tested code that is ready to be deployed to production. Continuous Delivery and Continuous Deployment take the next step.
Continuous Delivery vs Continuous Deployment
There is a subtle difference between Continuous Delivery and Continuous Deployment that is elegantly explained in a blog post by Jez Humble, author of Continuous Delivery. Martin Fowler prefaces his link to Jez’s blog post by stating that the difference is a business decision about the frequency of deployment into production. Jez defines Continuous Deployment as:
The practice of releasing every good build to users - a more accurate name might have been "continuous release".
And contrasts that with Continuous Delivery:
Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT. Implementing continuous delivery means making sure your software is always production ready throughout its entire lifecycle - 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.
In summary, continuous delivery is the process of preparing an application for release and continuous deployment is the process of actually releasing it. As I mentioned above, it is a subtle difference, but an important one. If your organization is in a state where releases are pushed to production several times a day, such as is the case for Amazon and Netflix, then you are practicing continuous deployment, but if you are building components that are ready to be deployed to production, at the push of a button, then you are practicing continuous delivery.
Regardless of whether you are practicing continuous deployment or continuous delivery, the key to enabling both is the creation of a deployment pipeline that is run by automated tools.
Jez Humble and David Farley, authors of Continuous Delivery, define a deployment pipeline as
An automated manifestation of your process for getting software from version control into the hands of your users.
In other words, when a developer checks source code into a source code repository, there is a set of steps that that source code must pass through before it is ready to be published to production. For example, you might define a pipeline that includes the following steps:
- The source code must be compiled and unit tests must run
- The code must pass through static code analysis to validate that the tests are valid (code coverage) and that the code adheres to quality standards
- The code must be tested in integration with the holistic application
- The integrated application must be load tested to ensure that it will perform well
- The tested and integration must be deployed to a user acceptance testing environment for human validation, such as in a blue/green deployment environment
- The application must pass through a canary test in production (a set of real production users are sent to the canary machines and the logs are monitored for failure)
- After canary testing passes then the application can be fully deployed to production
However you decide to define your pipeline, the important thing is to identify those “gates” that your application must pass through to reach production. And your CI/CD tool, such as Jenkins, will allow you to implement a deployment pipeline.
In my next post, I will introduce Jenkins and build a tool that will enable Continuous Integration, Continuous Delivery, and Continuous Deployment.