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.
Intent
The intent of Continuous Delivery is to expose inefficiencies and get rapid feedback on the codebase, build scripts and the deployment pipeline so that any issues can be remedied quickly. The techniques promote a holistic optimisation approach that considers the whole system and how it is built rather than focussing on just one part of it as with localised optimisation.
An additional side benefit is that once a team begins to get feedback quickly and easily on their codebase and the deployment scripts, they begin to build more frequently and so get feedback more frequently providing a continuous stream of information on code health and the deployment approach.
Compared to Traditional Release Cycles
Traditional approaches tend to focus on only a few highly organised deployments scheduled throughout the year, often drifting towards doing the least number of deployments possible so as not to disrupt the production environment.
Protecting the production environment from disruption and the potential issues from failed deployments is a defensive strategy that discourages teams from deploying their code, prevents an organisation's understanding of how to deploy code safely and can actively prevent change impacting an organisation's ability to respond to the market effectively.
Most organisations that employ a defensive approach with a few fixed deployment dates throughout the year, such as quarterly deployments for example, tend to also generate overbearing and complex deployment processes as product releases from multiple projects are stacked up over a period of 3 months ready for the single big bang deployment. The situation unravels quickly as the complexities and dependencies between the large number of releases are realised during the deployment process often resulting in failed builds, changes being backed out and partial success at best.
These approaches although intending to protect the production environment tend to instead promote complexity, anxiety, stress on the system and ultimately failure of the deployment process, and can actually cause the very situation that they are trying to avoid.
Anxiety in the workplace can lead to a hyper sensitivity to failure and may well cause a deployment team to over-compensate by introducing even more process and schedule even less deployment dates as a result, compounding the problem for next time a deployment is scheduled. Here a deployment team is running away from deploying code and evolving the organisation.
More Deployments More Often
Rather than focussing on doing deployments less often and running away from change, taking the counter intuitive approach and running towards change and embracing it with both arms, i.e. doing more deployments more often can surprisingly promote a safe deployment approach, protect the production environment and enable an organisation to evolve quickly.
More deployments more often leads to smaller and more manageable deployments that introduce small amounts of change more often. The changes are very small by comparison and easy to resolve if there are issues, and the teams get to practice releasing their code more often leading to an improved understanding and safer deployments.
This strategy then promotes confidence in the workplace as code is constantly deployed and tested and the organisation learns how to handle failures without major consequences.
Automating the deployments then paves the way for them to be smaller, easier to handle, repeatable and done more often.
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
Feature Toggles
Feature Toggles allow for features to be turned on/off via a configuration file or similar. This approach allows for features that comprise numerous small changes to be deployed in a flow based "pull" approach without impacting production until the feature dependencies have all been deployed.
Feature toggles then allow for the feature to be broken up into smaller more manageable work items during development that can be deployed as and when they are ready without compromising production or an agile approach.
See Also
References
- Continuous Delivery, Humble J, Farley D, 2011