CD is a set of practices and principles that aim to streamline and automate software delivery from commit to production. Teams and organizations practice with the goal of deploying software to production on demand at any time without impacting service availability. The main objective of CD is that software should always be in a deployable state and software release should be a fast, repeatable process.
This section is a quick overview of CD, what it consists of, and how it can help your organization achieve better and faster software delivery.
CD practices
Some of the practices that underpin CD are set out here:
- CI: CI means that code changes are integrated into the source code repository quickly and regularly. Automated builds and tests are triggered with each code commit, providing rapid feedback to developers. Consistent, reliable builds are at the foundation of a trustworthy CD process.
- Continuous testing: This includes unit tests, integration tests, and end-to-end (E2E) tests. Test suites are executed automatically during the pipeline to catch regressions early and increase your confidence in the quality of the system.
- Small, frequent releases: Instead of large, infrequent releases, CD tries to break down features and changes into small, manageable chunks that can be released more frequently. This reduces the risk of introducing regressions and makes it easier to identify and fix problems.
- Trunk-based development: A software development methodology in which developers divide their work into small batches and merge each batch into the trunk at least once a day. This approach is in contrast to more complex branching strategies such as feature branching or Gitflow, in which developers create separate branches for different features or bug fixes.
- Deployment pipeline: The entire release process, from building the code to deploying it to production, is automated using a pipeline. The automated pipeline can run such tasks as the following:
- Compiling code
- Executing unit tests
- Building software artifacts as container images
- Progressively deploying the app on different pre-production environments where different kinds of automated or manual tests can be performed
- Finally releasing the application to production
The following diagram represents an example pipeline, starting when there is a new commit in the source code repository. The tasks represented in the diagram and the ones listed previously are examples. The exact pipeline sequence changes depending on factors such as the application itself, the programming language, and the framework, as well as specific organizational contexts:
Figure 1.1 – A high-level look at a software delivery pipeline
That process, with those practices, can help you achieve improved software delivery performance, as described in the next section.
The impact of CD on software delivery performance
The DevOps Research and Assessment (DORA) research program has identified CD as one of the main capabilities driving software delivery performance, as measured by DORA’s four key metrics.
The following list shows those four metrics and how they can help you improve your software delivery performance:
- Deployment Frequency: How often code changes are deployed to production.
CD encourages more frequent deployments because it automates the deployment process and ensures that code changes are always production ready. Teams practicing CD can deploy changes to production on demand, often multiple times a day. Compare this to traditional approaches that might have longer release cycles.
- Lead Time for Changes: The time it takes to go from code commit to a production-ready release.
CD streamlines the software development process, enabling faster development cycles and reducing delays. CD automates steps in the delivery pipeline, such as building, testing, and deploying, which reduces manual intervention and wait times.
With CD, code changes are continuously integrated, tested, and delivered, shortening the time from development to production. Frequent, small releases accelerate TTM.
- Change Failure Rate: The percentage of changes or deployments that fail or require rollback.
CD emphasizes continuous testing, including unit tests, integration tests, and acceptance tests. This reduces the chance that defects and errors make their way into production.
Automation, in general, makes the release process repeatable and less error-prone because almost nothing is left to interpretation. Frequent, smaller releases make it easier to identify and fix issues early in the development process, reducing the likelihood of catastrophic failures in production.
- Time to Restore Services: The average time it takes to restore services after a production failure.
CD practices typically include automated monitoring and alerting in production environments. This helps teams detect issues quickly. When issues do occur, CD enables rapid rollback or forward fixes. Automated deployments make it easier to apply fixes and quickly get the system back to a working state.
See https://dora.dev/ for more info on DORA and the four key metrics.
In the rest of this chapter, we describe the most important underlying CD practices in more detail, starting with CI.
United States
Great Britain
India
Germany
France
Canada
Russia
Spain
Brazil
Australia
Singapore
Hungary
Ukraine
Luxembourg
Estonia
Lithuania
South Korea
Turkey
Switzerland
Colombia
Taiwan
Chile
Norway
Ecuador
Indonesia
New Zealand
Cyprus
Denmark
Finland
Poland
Malta
Czechia
Austria
Sweden
Italy
Egypt
Belgium
Portugal
Slovenia
Ireland
Romania
Greece
Argentina
Netherlands
Bulgaria
Latvia
South Africa
Malaysia
Japan
Slovakia
Philippines
Mexico
Thailand
