The key aspects of Software Delivery Performance which lead to improved business outcomes are:
- High deployment frequency
- Low lead time for changes
- Low change failure rate
- Low time to restore service
The delay and much of the extra effort in many software delivery processes is hiding in long-lived branches and a series of disjoint, infrequently updated test environments. Continuous Integration (CI) and Continuous Delivery (CD) processes address these problems by encouraging development and delivery of changes in small, frequently released batches from a single source.
Delivering a continuous flow of small batches of change to customers means:
- customers get to take advantage of work as it becomes available and get value out of it
- reduces the work in progress trapped inside the delivery pipeline when it stops for some reason like a critical bug
Let’s introduce the practices of Continuous Integration and Delivery, which are commonly abbreviated CI/CD.
Continuous Integration
Continuous Integration is a practice:
that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
By integrating regularly, you can detect errors quickly, and locate them more easily.
ThoughtWorks
By integrating regularly, software development teams avoid long-lived branches. Long-lived branches are generally difficult to integrate back into an active software codebase as the rest of the codebase is changing while the branch is active, diverging from the branch’s starting point.
A project’s Continuous Integration process should compile the code, run its unit tests, produce an artifact, and publish it to a repository. Each published artifact is a candidate for deployment that can be tested and possibly delivered to customers. The CI process may also build and publish environment-specific configuration artifacts that can accompany a generic application artifact on its deployment journey.
Building, testing, and publishing a release candidate on each change, or a small time window of change such as 5 minutes, is essential to preserving the option to deliver in small batches. One of the benefits you get when each build is treated as a release candidate, is that a problem in a given build can be avoided by selecting a previous or subsequent build. Customers are likely to get more value out of the build from a few changes ago than having to stick with the one from last month.
This leads to the next practice, where the release candidate is sent on its way towards customers by deploying it into a test environment.
Continuous Delivery
Continuous Delivery is a practice that builds on Continuous Integration that:
[ensures] our code is always in a deployable state, even in the face of teams of thousands of developers making changes on a daily basis. We thus completely eliminate the integration, testing and hardening phases that traditionally followed “dev complete”, as well as code freezes.
Jez Humble
When delivery teams use Continuous Delivery, a release candidate built by the CI system is deployed into test environments frequently. ‘Frequently’ might be ‘every change’, once per hour, or (maybe) once per day. After deployment, a release candidate’s functionality is verified with an acceptance test suite, and that artifact is promoted on up to the next environment without changing the artifact. And yes, when you adopt continuous delivery, you will need to automate your deployment process or you will tire quickly.
Promotion of a single generic application artifact across environments eliminates a lot of toil by people. Promoting a single artifact also increases confidence that that artifact will work well for customers. This is because it receives additional testing in each environment instead of being rebuilt anew from a source branch that diverged from the application’s main source code line long ago.
When a problem is detected in a particular release candidate, the team’s delivery pipeline stops the promotion of that build, the team fixes the bug, and lets the delivery process go back to work. Keeping code in a deployable state preserves the option to deploy at any time and keep lead times low (#2 on the Aspects of High Performance Delivery list).
Summary
Much of the extra effort and delay in software delivery processes is hiding in long-lived feature branches and test environments built from long-lived release branches.
Continuous Integration and Continuous Delivery eliminates the places where changes languish. They force changes to be integrated and work alongside other changes sooner. This validates change in small batches, eliminates large drifts, and provides quick feedback. A continuous stream of small batches makes those changes available for delivery to customers sooner and with lower risk than a large batch of changes. Together, Continuous Integration and Delivery maximize the opportunities for you to deliver value to customers so that you can gather feedback and repeat the cycle.
#NoDrama
