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.

Continuous integration (CI) is a set of software development practices for frequently integrating code changes. Each time a developer integrates changes (usually at least daily), those changes are automatically verified and tested. This means that there is always an up-to-date build ready to deploy.

The practice of CI was created to solve integration and compatibility problems caused by the old approach of developers working in isolation for an extended period on their version of code and then attempting to merge their changes into a shared code base.

CI follows the counterintuitive principle that if something is painful, you can make it less painful by doing it more often. This is based on the understanding that the integration effort is exponentially proportional to the amount of time between integrations (as found on https://martinfowler.com/articles/originalContinuousIntegration.html#TheMoreOftenTheBetter).

The next section describes how to bring these principles to your software development process.

How to implement CI

Here is a list of fundamental practices that a team should consider following to implement CI:

• Trunk-based development: As described previously, developers divide their own work into small batches and merge that work into the main code branch (trunk) at least once a day.
• Automated builds: For every change committed to the repository, the application is automatically compiled, built, and tested without manual intervention. This helps ensure that the software is always in a state that can be deployed to production. Artifacts produced by the CI build should be used by all subsequent deployment tasks. An automatic build is run at least once a day.
• Continuous testing: Automated tests run every time a change is committed, including unit tests, integration tests, and other types of automated tests. This helps ensure that new code doesn’t break existing functionality. Immediate feedback from these tests allows developers to fix issues quickly before those issues cause bigger problems. Tests should run successfully at least once a day, and if they fail, the team prioritizes fixing the problem.
• Collaboration: This is probably more a consequence of the previously listed elements than a principle to implement. With all team members committing to the shared repository regularly, there’s a continual exchange of ideas and code. This openness not only improves the quality of the software but also enhances team dynamics, as everyone can see what others are working on. It also encourages developers, testers, and operations teams to work more closely together. This collaboration breaks down silos and promotes a more cohesive approach to software development, in which everyone is aware of the goals and challenges of the project.

Now that we’ve covered the main elements of CI, let’s explore continuous testing.