Continuous Delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be readily released at any time. Continuous Delivery is enabled through a deployment pipeline that breaks down the software delivery process into stages, with each stage verifying the quality of new features from multiple perspectives including the prevention of errors, findings and security vulnerabilities from impacting end users. The pipeline should provide rapid feedback to the team and visibility into the flow of changes to everyone involved in delivering the new features.
There is typically no such thing as a standard pipeline, in part as applications are very different in terms of architecture, technologies and complexity, but a typical CD pipeline will include the following: build automation and continuous inspection, test automation, and deployment automation.
Build automation and Continuous Inspection
The pipeline starts by automating the building of binaries to create the release deliverables that will be passed to the subsequent stages. New features implemented by the developers are integrated into the central code stream on a continuous basis, built and continuously inspected. This provides the most direct feedback cycle that informs the development team about the health of their application code through evaluating the results of builds, unit tests, source code analysis tests, web vulnerability tests and open source policy violations – automating a configurable continuous inspection toolchain provides rapid feedback to the developers where they need it, and also aggregates metrics to assess readiness for test and deployment automation.
The new version of an application is then rigorously tested to ensure that it meets all desired system qualities, ensuring that functionality, security, performance or compliance — are verified by the pipeline. The stage may involve different types of automated or (initially, at least) manual activities.
A deployment is required every time the application is installed in an environment for testing, but the most critical moment for deployment automation is production rollout. Since the preceding stages have verified the overall quality of the system, this can be a low-risk step. The deployment can be staged, with the new version being initially released to a subset of the production environment and monitored before being completely rolled out. The deployment is automated, allowing for the reliable delivery of new functionality to users within minutes, if needed.
The deployment pipeline is usually supported by platform provisioning and system configuration management, allowing teams to create, maintain and tear down complete environments automatically.
Where multiple stages in a deployment pipeline involve collaborative groups who oversee and track the progress though any necessary approvals and delivery, orchestrating the release process provides a high level view of the entire pipeline, supporting the ability to define and control the stages, and monitor insight into the overall software delivery process.
Recommendations for achieving Continuous Delivery
For most organizations it may not be feasible to adopt Continuous Delivery all at once, and a better approach is to focus on identifying the prioritized bottlenecks and improving each of them in the delivery process as you continue to iterate and measure improvements.
Here’s an example of a Continuous Delivery Pipeline process