continuous delivery (CD)

Continuous delivery (CD) is a software release approach in which development teams produce and test code in short cycles, usually with a high degree of automation. This process enables development teams to build, test and deploy software quickly by encouraging more incremental updates, rather than a complete overhaul of a given product.

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 the staging environment, which should make cause and effect observable. Code can be tested for all aspects of functionality, including business rule logic, which should reduce unexpected performance problems in production.

Content Continues Below

When CD is ongoing and testing occurs early, a concept sometimes referred to as shift left, developers can work on fixes before they move on to another aspect of the development project, minimizing the difficulties that occur when a person has to refocus on a task after a period of time.

Other forms of testing in CD include user interface (UI) testing, load testing and integration testing.

Continuous delivery benefits

CD simplifies software deployment compared to other 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 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, CD 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, CD offers developers a way to get back to doing smaller, more frequent releases that are more reliable, predictable and manageable.

Continuous integration and continuous delivery

Continuous delivery is an extension of continuous integration (CI). Whereas CI deals with the build and initial code test part of the development cycle for each release, CD focuses on what happens with a committed change after it is 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 CD are often paired as CI/CD, as CD acts as a continuation of CI. With CD, any commit that passes the automated tests can be considered a valid candidate for release. CI and CD can enable an organization to have automated testing and staging processes that let the developers decide when and how often to deploy their code into production.

Continuous delivery process

In CD, automated builds, tests and staging deployments are integrated into one continuous process. CI/CD processes commonly include four phases: the component, subsystem, system and production phases.

The component phase is typically considered part of continuous integration, although it can also be seen as an element of continuous delivery. Developers write and commit the smallest distributable units of code. The code gets tested through reviews, unit tests and static analysis. These tests on small amounts of code are more efficient than end-to-end tests and isolate issues.

Subsystem phases focus on multiple loosely coupled components. This code should be executable. Tests performed on the subsystem level include functional, performance and security tests. The tests performed in subsystem phases ensure that the developed code can meet the quality standards of an end user and the specifications of the project.

System phases are integrated subsystems that still require tests of the UI and networks and can still require other functional, performance and security reviews. At this phase, the application components can be kept separate to form microservices or integrated together as one complete system.

In the production phase, independent subsystems or integrated systems are ready to be deployed into the production environment. Blue/green deployment is a common method of deployment for CD, in which 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 known-good environment while the software team addresses the problem.

Continuous delivery tools

There are a plethora of open source and commercial tools available at each stage of continuous delivery and ones that transcend continuous integration and delivery.

Generally, software teams that practice CI/CD 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 model from development to test to production and integrated development environments to ease the complication of build and test. These tools all integrate with a CI/CD pipeline tool, such as Jenkins or CircleCI. Organizations also rely on monitoring in production and capacity management, and tools for these purposes can be integrated with the CI/CD pipeline as well.

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.

Public cloud providers, such as AWS, also offer integrated sets of CI/CD tools, which developers and IT operations professionals can use from code development through deployment to production, as well as for monitoring and scaling.

Continuous delivery vs. continuous deployment

Continuous delivery and continuous deployment are similar terms that are commonly confused with each other. In continuous delivery, code flows automatically through multiple steps to prepare it for production release but does not automatically go live. The code changes must first be 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.
This was last updated in September 2018

Continue Reading About continuous delivery (CD)

Dig Deeper on IT Ops Implications of Continuous Delivery

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Should IT organizations standardize on one CI/CD pipeline or use different pipelines to match different projects' requirements?
Thanks - great article for understanding the basics of Continuous Delivery. You might also find it interesting to look at IT Central Station where real users review and rate many tools in this category: Currently rated #1 is CA RA. Hope this is helpful.


File Extensions and File Formats

Powered by: