TechTarget.com/searchitoperations

https://www.techtarget.com/searchitoperations/definition/continuous-delivery-CD

continuous delivery (CD)

By Alexander S. Gillis

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 to improve software quality. This process helps development teams build, test and deploy software quickly by encouraging more incremental updates as opposed to spending a large portion of time on a complete overhaul of a given product.

Continuous delivery is a popular approach for software delivery, especially for teams that practice DevOps. It is typically paired with continuous integration to form a chain of processes for software development, deployment and feedback loops called a CI/CD pipeline. CD processes normally have high degrees of automation.

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.

Continuous integration/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 following are general stages in a CI/CD process:

1. Source. The first step in the pipeline is where developers write and commit the smallest distributable units of code. Automation features are typically triggered either by code changes in the repository, user-initiated workflows or automatically scheduled changes. 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.
2. Build. The source code is collected from the code repository, including its libraries, modules and dependencies, and compiled into an executable file. Tools log the process and denote errors to fix. Some builds might employ scripts to translate the executable file into a packaged or deployable execution environment, such as a VM or a Docker container.
3. 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 network tests. They might 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. If the tests fail at this stage, feedback is given to the developers to fix.
4. Deploy. Finally, the software should be ready to be deployed into the production, staging or beta 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. If any issues are discovered after, the switch is rerouted back to the previous environment, where the software team addresses the problem. This avoids the downtime involved in pushing out typical updates.

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:

• Automation. Continuous delivery facilitates test automation and automated builds.
• 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 deployed into the production environment is found, 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 lets many developers 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.

CI/CD environments are an important security concern to watch out for, however. Misconfiguration could expose sensitive data and create an entry point for malicious actors.

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 teams also strive 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 make this possible.

Continuous integration and continuous delivery

Continuous delivery is an extension of continuous integration, a software development 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, CD 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 lets an organization have automated testing and staging processes, which help developers decide when and how often to deploy their code into production.

It is important to note, however, that the CD in CI/CD might 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 is also commonly confused.

The key difference is 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, potentially involving manual testing and quality assurance to do so.

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 is often a time lag between a software review and software 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 is 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.
• 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 tools for production and capacity management as well as containers for consistent software deployment in different environments. These different environments include development, test, production and integrated development environments.

Public cloud providers such as Amazon Web Services (AWS) and Microsoft Azure also offer integrated sets of continuous delivery tools. Developers and IT operations can use these tools for code development, deployment, and production as well as for monitoring and scaling.

An incomplete list of CI/CD 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.
• Azure Pipelines.
• Chef.
• CircleCI.
• CloudBees CodeShip.
• Codefresh.
• DeployBot.
• Google Cloud Build.
• Jenkins.
• Octopus Deploy.
• Spinnaker.
• JetBrains TeamCity.

Continuous delivery provides an organization with a fast-paced development environment. Learn more about the pros and cons of a CI/CD pipeline.