What is continuous delivery?
Continuous delivery (CD) is an approach for software delivery in which development teams produce and test code in short but continuous cycles, usually with high degrees of automation, to improve software quality. 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. It is typically paired with continuous integration (CI) to form a chain of processes for software development, deployment and feedback loops called a CI/CD pipeline.
In continuous delivery, code is delivered on a regular basis to user acceptance testing or to a staging environment. Code is tested for all aspects of functionality to reduce unexpected performance problems in production. Any component that passes the automated tests is a valid candidate for release. At this final stage, continuous delivery triggers a final human check and then a push to deployment. Alternatively, the build can be automatically deployed, a step called continuous deployment.
With continuous delivery, testing occurs early -- a concept sometimes referred to as "shift left." This lets developers work on fixes before they move on to other aspects of development.
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 following are general stages in a CI/CD process:
- Source. The first step in the pipeline is where developers write and commit the smallest distributable units of code. 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.
- Build. The source code is collected from the repository, linked to libraries, modules and dependencies, and compiled into an executable file. Tools log the process and denote errors to fix. Some builds may employ scripts to translate the executable file into a packaged or deployable execution environment, such as a VM or a Docker container.
- Test. At this point, the code should be executable. It is tested at the subsystem level, including functional, performance and security tests. These ensure that the developed code meets the quality standards of an end user and the specifications of the project. Integrated subsystems require UI and networks tests, and may still need other functional, performance and security reviews. Automate these tests wherever possible. At this phase in the pipeline, the application components can be kept separate to form microservices or integrated together as one complete system.
- Deploy. Finally, the software should be ready to be deployed into the production environment, but first, the code is manually checked one last time. Blue/green deployment is a common method of deployment for continuous delivery, where two environments are configured identically -- one environment serves 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. Any issues discovered after the switch are rerouted back to the previous environment where the software team addresses the problem.
Pairing continuous integration with continuous delivery ensures code worked on by multiple developers from multiple locations is integrated into a single repository. Note that this requires continuous testing to keep up with workflows.
What are the benefits of continuous delivery?
Continuous delivery offers several benefits over traditional application development and deployment, including Waterfall:
- Simplicity. A development team spends less time preparing a code base for release and doesn't bundle multiple individual changes together for a large release. Instead, developers continuously update and release code in small increments.
- Faster debugging. Small releases reveal bugs in new code quickly. For example, if a bug is found in code deployed into the production environment, developers can isolate the offending code to one of the last incremental updates, fix the problem, test the code, redeploy it and receive new feedback.
- Faster development cycles. Continuous delivery enables faster application iterations, as it enables many developers to collaborate on and create code at different times without harming other projects. If an iterative process becomes unwieldy due to increasing project complexity, continuous delivery offers developers a way to get back to 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. The goals of DevOps and continuous delivery align to allow a continuous workflow. One of the main focuses in continuous delivery is to build, test and release software quickly, which DevOps also strives for.
Large and small DevOps organizations use continuous delivery for benefits such as faster and higher quality software development, release processes and code commits. DevOps and continuous delivery can be overlapping processes, and having these processes happen in shorter cycles helps makes this possible.
Continuous integration and continuous delivery
Continuous delivery is an extension of continuous integrationI, a software engineering practice in which frequent, isolated changes are immediately tested and added to a larger code base. Whereas 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 are tested and integrated quickly with unit and integration tests. Continuous integration gives 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.
With continuous delivery, any commit that passes the automated tests is potentially a valid candidate for release. CI and continuous delivery 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 refer to another phrase that is closely related: continuous deployment.
Continuous delivery vs. continuous deployment
Continuous delivery and continuous deployment are similar concepts that are commonly confused with each other. Both are used in concert with continuous integration -- which is why the term CI/CD also can be confusing.
The key difference is with what happens during the deployment process. 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 to do. 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 also usually involves a production-like staging area. 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. Some tools offer functionality across aspects of both CI and CD.
Generally, software teams that practice CI/CD use various tools:
- 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 tools all integrate within a continuous pipeline, and some offer capabilities that are useful in multiple steps. Organizations also rely on monitoring in production and capacity management. Teams might also rely on containers for a consistent software deployment in different environments -- from development to test to production and integrated development environments -- to ease the complications of build and test.
Public cloud providers such as AWS and Microsoft Azure 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.
An incomplete list of tools that perform some aspect of continuous delivery (and in some cases other CI/CD steps) includes the following:
- Ansible Tower
- Atlassian Bamboo
- AWS CodeDeploy
- Octopus Deploy