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.

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. 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.

See Also

Release Planning

References

1. Continuous Delivery, Humble J, Farley D, 2011