continuous delivery (CD)

Continuous delivery (CD) is an approach for software delivery in which development teams produce and test code in short but continual cycles, usually with high degrees of automation. This process enables development teams to build, test and deploy software quickly by encouraging more incremental updates, rather than spending a large portion of time on a complete overhaul of a given product. Continuous delivery is popular approach for software delivery, especially for teams that practice DevOps.

Continuous delivery aims to make feedback loops as short as possible to improve software quality. Code is delivered on a regular basis to user acceptance testing (UAT) or a staging environment. Code can be tested for all aspects of functionality, which should reduce unexpected performance problems in production. Any component that can pass the automated tests can often be considered a valid candidate for release.

With continuous delivery, testing will occur early -- a concept sometimes referred to as "shift left." This lets developers work on fixes before they move on to other aspects of development.

Continuous delivery pipeline

There is not one standard continuous delivery pipeline. The common denominator between typical pipelines is the focus on subjects like automated builds, tests and staging deployments into one continuous process.

The first step in the pipeline is where developers write and commit the smallest distributable units of code. This step can be thought of as an element of continuous delivery. The code gets tested by reviews, unit tests and static analysis. Tests on small amounts of code can be more efficient than end-to-end tests.

At this point, the code should be executable. Tests should be performed on the subsystem level, which includes include functional, performance and security tests. The tests performed here should ensure that the developed code can meet the quality standards of an end user and the specifications of the project.

Next, integrated subsystems will require UI and networks tests -- and may still need other functional, performance and security reviews. At this phase in the pipeline, the application components can be kept separate to form microservices or integrated together as one complete system.

Next, the software should be ready to be deployed into the production environment. But, before deployment, the code is manually checked before being accepted for deployment.

Blue/green deployment is a common method of deployment for continuous delivery, where two environments are configured identically. One environment is used to serve end users, while the other is ready for new code to deploy and undergo testing, such as a load test to measure performance at a high capacity. When the released code is deemed ready, the environments switch traffic sources, and the new code becomes available to users. If any issues are discovered after the switch, the traffic can be rerouted back to the previous environment while the software team addresses the problem.

The tests performed should be automated wherever possible. Other strategies in continuous deployment can also be employed. For example, continuous integration (CI) can also be paired with continuous delivery, which ensures code worked by multiple developers from multiple locations are integrated into a single repository. Continuous testing then will also be needed to keep up with workflows.

Continuous delivery benefits

Continuous delivery simplifies software deployment compared to methods such as Waterfall, as a development team does not have to spend as much time preparing a code base for release, nor are multiple individual changes bundled together for a large release. Instead, a development team continually updates and releases code in small increments.

Small releases will reveal bugs in new code quickly. For example, if a development team deploys code into the production environment and a bug is found, developers will be able to isolate the offending code to one of the last incremental updates. They can remove the problem, test the code, redeploy it and receive new feedback.

Additionally, continuous delivery enables faster application iterations, because many developers can collaborate on and create code at different times without harming other projects.

If an iterative process is becoming unwieldy due to increasing project complexity, continuous delivery offers developers a way to get back to doing smaller, more frequent releases that are more reliable, predictable and manageable.

Continuous delivery and DevOps

Continuous delivery is commonly used in the DevOps paradigm. DevOps is meant to be a collaborative approach to the tasks performed by application development and IT operations teams, often with an emphasis on automation. Continuous delivery helps facilitate this process by allowing the ongoing building, testing and delivery of software.

The goals of DevOps and continuous delivery line up in allowing a continuous workflow. One of the main focuses in continuous delivery is to build, test and release software quickly, which DevOps will also strive for. Large and small DevOps organizations will use continuous delivery for benefits like faster and higher quality software development, release processes and code commits -- since DevOps and continuous delivery can be overlapping processes. Having these processes happen in shorter cycles helps makes this possible.

Continuous integration and continuous delivery

Continuous delivery is an extension of continuous integration. CI is a software engineering practice in which frequent, isolated changes are immediately tested and then are added to a larger code base. Where CI deals with the build and initial code test part of the development cycle for each release, continuous delivery focuses on what happens after committed changes are built.

CI is a way to merge all developers' copies of code into a code base frequently. Isolated changes can be tested and integrated quickly with unit and integration tests. Continuous integration can give a development team specific feedback on changes or additions to the code base. If a bug is introduced, the code tests in CI should reveal it before the code moves closer to release.

CI and continuous delivery are often paired together as CI/CD, as continuous delivery acts as a continuation of CI. With continuous delivery, any commit that passes the automated tests can be considered a valid candidate for release. CI and continuous delivery can enable an organization to have automated testing and staging processes, which then further enable developers to decide when and how often to deploy their code into production.

It is important to note, however, that the CD in CI/CD may also be used as a stand-in for another phrase.

Continuous delivery vs. continuous deployment

Continuous delivery and continuous deployment are similar concepts that are commonly confused with each other. Both share the acronym CD and can be used with continuous integration -- which is why the term CI/CD can be confusing.

The biggest and most notable difference is with what happens during the deployment process, concerning the deployment pipeline. In continuous delivery, code flows automatically through multiple steps to prepare it for production deployment, but does not automatically go live. The code changes must first be manually approved, and there is likely manual testing and quality assurance (QA). However, in continuous deployment, code can be automatically tested, vetted and released into a production environment, where it is automatically scaled with user demand and monitored for any problems that would necessitate a rollback.

Continuous delivery vs. continuous deployment
Continuous delivery and continuous deployment differ in how code reaches the live production environment.

Continuous delivery also usually involves a production-like staging area. In continuous delivery, there may often be a time lag between a software review release -- when changes are manually accepted -- and when new code is released to production.

This is where the advantage of continuous deployment comes in. The time lag found in continuous delivery is eliminated. Continuous deployment also does not require a staging area for code changes. Instead, automated testing is integrated early in the development process and continues throughout all the phases of the release.

Both continuous delivery and deployment rely on real-time infrastructure provisioning and application monitoring tools to discover problems not caught in the testing feedback loops. 

Continuous integration, delivery and deployment are collectively referred to as continuous software development. They are all also associated with the Agile and DevOps methodologies.

Continuous delivery tools

There are a plethora of open source and commercial tools available at each stage of continuous delivery, as well as ones that work for continuous integration and delivery.

CI/CD pipeline
This example CI/CD pipeline covers code development and delivery and a sampling of tests that help ensure releases are production-ready.

Generally, software teams that practice continuous delivery use a version control system to manage code; an automated build engine; unit, functional and integration test systems; performance testers for normal load and stress tests; configuration management tools; and an artifact repository. These teams might also rely on containers for a consistent software deployment in different environments -- from development to test to production and integrated development environments. This is to ease the complications of build and test.

These tools all integrate with a continuous pipeline tool, such as Jenkins or CircleCI. Organizations also rely on monitoring in production and capacity management.

Public cloud providers, such as AWS, also offer integrated sets of continuous delivery tools. Developers and IT operations can use these tools from code development through to deployment and production, as well as for monitoring and scaling.

This was last updated in September 2020

Continue Reading About continuous delivery (CD)

Dig Deeper on IT Ops Implications of Continuous Delivery