Continuous Delivery
Introduction
The primary purpose of Continuous Delivery is to enable organizations to deliver any type of changes such as new features, configuration changes, bug fixes and experiments into production or in the hands of the users in a safe, rapid and sustainable way through the automation and streamlining of the software delivery process. It ensures software is production ready and in a releasable state throughout its lifecycle. To achieve this Scrum Teams need to have immediate automated feedback on release-readiness every time they make a change to code, or infrastructure configuration. This involves implementing practices such as build automation, configuration management and automated testing.
Continuous Delivery enables Scrum Teams to become more efficient in their development process. It allows them to reduce their time to market and gain feedback from stakeholders quicker - all in pursuit of developing valuable product Increments to customers.
Configuration Management
The phrase “but it works on my machine” has become a humorous yet frustrating remark when discussing software or deployment issues. It highlights the fact that a piece of software may behave differently in various environments, and what works on one machine may not work on another due to differences in configurations, dependencies, or other factors.
In order for Scrum Teams to release software repeatedly and reliably they should automate repetitive manual processes such as build, regression testing, provisioning of the required infrastructure, and deployment. They also need to use version control on all source code, test code and definitions, and configuration descriptions. This way, Scrum Teams can be confident that any new environment reproduced from the same configuration is identical. They can avoid unnecessary delays and can quickly compare versions of an environment to identify what has changed between them when issues arise.
Continuous Integration
The development practice of Continuous Integration is essential to Continuous Delivery. The key word here is integration, meaning, in order to catch and fix issues early and continuously in development, Developers commit and integrate their changes into main/ trunk on a daily basis. Scrum Teams that practice continuous integration do not use long lived feature branches, instead they integrate their changes into the main/ trunk branch at least once a day to improve collaboration among team members, reduce integration challenges, increase quality and enable faster and reliable delivery of software.
Each check in is validated by an automated build, and an automated unit, integration and acceptance tests, which brings us to the next ingredient of automated testing.
Automated testing
Testing is not something that Developers should do after they have developed the functionality, instead testing is something that Developers should be doing all the time. Developers should build quality into the product in the first place. Full manual regression testing after development is not a good way to achieve high quality. In the longer run a lot of precious time can be saved and higher quality can be ensured by building a comprehensive suite of automated tests.
The process visualized in the figure above shows the following:
- A Developer checks in a change to the source control system
- The check-in triggers a build
- If the build succeeds, unit tests are run
- If the unit tests fail, the change has broken something and the team’s priority is to fix it; nobody should check something else in until the fix is in place
- If the unit tests pass, a production-like environment is created and automated integration and acceptance tests are run
- If the automated acceptance tests fail then the change has broken something and the team’s priority is to fix it, and so on. This process continues throughout the pipeline.
Some steps in this process are better suited to automation than others. Tasks that are repetitive and don’t require a person to make a decision, or make decisions based on whether a task or a test passes are easy to automate. Automating repetitive tasks can improve consistency and quality by eliminating human error resulting from task fatigue. Tasks that require informed decisions are difficult to automate, but automating mundane and repetitive tasks frees Developers to focus on things that require thoughtful consideration of data and alternatives.
Many Scrum Teams have Developers that specialize in helping with testing activities such as exploratory testing or helping to maintain and the suites of automated tests. That does not mean that these people are solely responsible for quality. Instead, everyone on the team is responsible for quality at all times. To help with this Developers create tests and a deployment pipeline to run those tests. A deployment pipeline is a process from check in to release in production. It enables visibility and Developers get fast feedback on the impact of the changes they have introduced.
What about Continuous Deployment?
Continuous Deployment is an optional extension to Continuous Delivery that can help a team to further reduce its delivery cycle time. While Continuous Delivery stops just before deploying to production and requires stakeholders, such as business decision-makers or regulators to make a decision (or provide approval) to deploy, Continuous Deployment takes the additional step of automatically releasing the build provided that it meets all release criteria.
Continuous Deployment does not require a decision step and deploys successfully tested product Increments into production automatically as part of the deployment pipeline.
Conclusion
Ultimately Continuous Delivery allows Scrum Teams to deliver valuable product Increments to customers faster in a sustainable and reliable way. Additional benefits include:
- Developers are able to obtain rapid feedback about the quality of their work. There are faster user feedback loops
- Improved quality. Quality is built early and continuously
- Reduced risk and enhanced disaster recovery
- Increased transparency. No big surprises or integration challenges caused by merging long-lived feature branches and big changes into main/ trunk
- Reduced costs, time and risks of delivering incremental value
- On-demand release capability. Releases become ‘non events’. Releases are fast and can be done at any point in time.
- Enabled flow of value
- Improved collaboration
Resources:
Further Reading:
Website: https://continuousdelivery.com/
Book: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble and Dave Farley, Addison-Wesley Professional, July 27, 2010, ISBN-13 978-0321601919