Continuous Delivery
Continuous Delivery builds upon Continuous Integration techniques and platforms to provide repeatable, easy and fast deployments to production.
Continuous Integration as a platform enables a rapid feedback response as features are completed, checked in to version control, built into binaries and a suite of automated tests are run against them to determine if there are any issues.
Continuous Delivery extends the feedback cycle to also include shipping the feature when it is done providing a rolling horizon of working changes into production, with a side benefit of providing rapid customer feedback as well as facilitating customer testing options such as A|B testing for example.
For a deployment process that is fast, easy and reliable, then teams will begin to naturally release more often and with confidence.
From customers' perspective they experience small incremental changes that evolve the customer experience over time, and arguably with small features, there is little training or change management needed.
Delivery Pipeline
A delivery pipeline is intended to be an automated mechanism for "...getting software from version control into the hands of your users."[1] A pipeline usually has monitoring and a push button interface to enable builds to be constructed and then deployed to environments, culminating in a deployment to production.
Guiding Principles
Some guiding principles behind a continuous delivery pipeline include:
- everyone contributes to keep the release plan updated and maintained, using a collective ownership principle
- minimise the need to human intervention by automating as much as possible to provide a reliable and repeatable process
- release small amounts of change more often to get more practice at releasing and constantly curating the product in production
- make releasing easy and it will be done more often, allowing more frequent feedback
- automated release processes allow for democratised releasing approaches were developers and testers can deploy on demand to their respective environments
Elimination of Problematic Release Candidates
Several stages in the pipeline may be setup such as code check in -> build and automated unit tests -> automated acceptance tests -> user acceptance test & approval -> release. If a release candidate fails at any step along they way then this is good feedback to indicate that some issues exist and need to be resolved before the candidate can be released. In this instance a "stop the line" culture works bast to halt the pipeline for this release and go back and fix the issues. Those release candidates that make it to the release stage without any issues then stand a good chance of being deployed.
Duplicate Production Environments
Often the development and testing environments are different from the target production environment, which can present unique issues from time to time. If there is sufficient budget then it can be a good idea to have duplicate production environments that can then be used via load balancing to divert traffic to test the new release on a production environment and provide feedback and confidence that it is working as expected.
If there are problems then the load balancing can divert traffic back to the original production environment until the issues are resolved.
When there is sufficient confidence the release can then be deployed to the remaining production environments.
It's good to also run an automated smoke test post release to provide technical feedback that the deployment with the new feature is working as expected, and if not, then an automated rollback process can be invoked to revert to the previous state before the release was started.
Race Conditions
If several teams are working concurrently on a common code base, then there is the potential for multiple check-ins to trigger the delivery pipeline automated processes and cause a "stack" of processes to be run. To avoid complications and race conditions forming, a good CI/CD server should be able to avoid surplus executions and bypass intermediate releases and focus on the latest release instead.
Backout
One of the main fears about deployment is if a defect in the code is also deployed and unexpected behaviour in production is experienced. Two strategies to counter this fear include:
- back out the change by redirecting traffic back to the original duplicate production environment
- redeploy a known stable previous version to the production environment and overwrite the change
See Also
References
- Continuous Delivery, Humble J, Farley D, 2011