Continuous Delivery is an extension of Continuous Integration. Where Continuous Integration ends with a tested, packaged product, Continuous Delivery takes that product and puts it into an automated release process. The end result of Continuous Integration and Delivery is the ability to take a product all the way from code to a production environment at the push of a button.
Continuous Deployment takes this concept further still, removing the requirement to “push a button” to release. Every deployment which passes integration successfully is deployed automatically to the live environment.
Both practises represent the transition from development of a system to its operation. See Teams for a description of how these responsibilities can be distributed in unified teams.
“We don’t have a release manager and there are no set weekly deploys. Developers and designers are responsible for shipping new stuff themselves as soon as it’s ready.” - GitHub Blog
Ideal continuous deployment processes should have the following characteristics:
Minimal human intervention
Minimise the amount of human effort required to deploy a product to a live environment. This ensures that personnel are working on value-add activities rather than repetitive “overhead” costs. Minimising human interaction also reduces a source of error, as people are typically poor at repeating complex tasks.
Deployments should be reliable, so that personnel are not worried about releases which have to be meticulously planned and executed. Deployments should become predictable, with high confidence and low risk.
The timing of deployments should matter less as organisations develop competencies in this space. Product technology decisions can be made to reduce dependencies or ensure data migrations do not interrupt normal processing. With these in place concepts such as release windows can be removed and deployments made at any time of day.
To achieve the objectives outlined above, consider the following suggestions:
- CD processes are automatically triggered from CI processes
- Sequential release of deployment packages through staging environments to production
- Use of deployment patterns such as blue-green deployments
Robust QA and approval processes
As CD approaches are an extension of CI, it is expected that CI processes (and particularly automated testing regimes) are already mature. This is particularly true for Continuous Deployment practises where the output of CI is automatically released to live.
- Low number of deployments to live environments found to have errors
- Automated release approval processes (Continuous Delivery may involve a manual approval step or deployment windows)
- Roll forward (i.e. create a new release) when issues occur in live rather than rolling back
Keeping relevant parties informed of releases is an important part of release practise. This may take the form of automatically created release notes, emails to customers, or IM-based notifications to internal teams.
- Agreed communication platform and channels
- Release notifications describing change and release information are created and distributed automatically
- Accessible user-facing release history and details
In rare cases that errors are not caught by CI processes, it is important to have robust monitoring software in place to detect any issues in live environments once the release process is complete.
- Ability to identify the build/release associated with any logged failures
- All errors are logged
- Wider performance monitoring and dependency monitoring tools are in place
- Failures are detected swiftly, and routed efficiently to development teams
Technology selection and coding patterns are put in place to support CD processes.
- Use of software patterns such as feature toggles
- Systems are designed to minimise or remove downtime caused by data migrations
- Data backup and restore processes are aligned to support disaster recovery scenarios
The following books are recommended to help develop competency in this area:
Jez Humble, David Farley
Once your software is ready to release to users it must be deployed. This book explains how to de-risk and efficiently manage your deployment pipeline to make releasing software as simple as possible.
Edit this page on GitHub
The content on this page is published under Open Source licenses via GitHub. To submit issues or provide feedback please visit the repository.Visit