What is the Continuous Delivery Pipeline?
The continuous delivery pipeline is an automated set of processes that use tools to compile, test, and deploy code for new software features. The purpose of a continuous delivery (CD) pipeline is to create a continuous management and release setting where bugs, compatibility issues, and security breaches are identified and fixed as early as possible.
Also called the “deployment pipeline,” the CD pipeline is the vehicle that drives iterative software application development. It breaks down the strategy of continuous integration and continuous delivery into stages so development teams can gather results incrementally, at each stage of the build. Developers are then able to run tests and make other assessments without having to wait until the entire workflow is completed.
Mastering Each Stage of the Continuous Delivery Pipeline
The goal of building a continuous delivery pipeline is to get new product features to end users as quickly as possible. This process—that begins with source control and ends with release—can be broken down into four stages: commit, automated acceptance, continuous deployment, and production release.
When the CD delivery pipeline is applied optimally, a new instance is begun at every stage of code check-in and only one build is tested at a time. Developers are notified immediately of status updates and fix code that does not meet minimum standards (or take out of version control) before it passes to the next stage.
The process of commit begins with each code check-in. New code is placed in a temporary, self-contained file system, compiled, and put through a series of tests. This stage should take approximately 5-10 minutes to complete.
Automated tests enacted during commit may include:
- Unit tests – small parts of an application, called units, are isolated and their individual methods and functions are tested for correctness.
- Split tests – developers test two parts of the application at the same time to determine which has better functionality. Split tests are also called “A/B tests.”
Unit tests help improve code design and can prevent the same bugs from occurring repeatedly, i.e. regressions. Once all specifications have been met, code moves to the next stage in the pipeline: automated acceptance.
2. Automated Acceptance
During this phase, automated scripts build an environment—or environments—that replicate what the application will encounter in production. Secondary testing is then performed to stress test new builds. Each version of code commit is automatically tested.
Sometimes called “smoke testing” or “build verification testing,” this stage of the pipeline examines basic functionality, like the ability to launch the application or how buttons respond in a near-production environment.
Acceptance testing can quickly identify flaws and ensures failures are dealt with by developers promptly, not kicked down the road for someone else to deal with later.
3. Continuous Deployment
In this stage, the developers undergo an ongoing cycle of interacting with the software, testing how it behaves, and making improvements by refining code. As with all stages of the pipeline, the process is automated and the intent is to minimize lead time from build to deployment.
New code that is tested and verified then moves to a staging and production environment where the live application is updated. Two types of tests that may be used are:
- Functional tests – tests the complete functionality of the application.
- Regression tests – tests new code with earlier versions of code to make sure it still functions correctly.
Continuous deployment is not synonymous with continuous delivery. Continuous delivery is when products are release-ready and manually pushed into production when a business decision is made to do so. In continuous deployment, updates to a feature are automatically pushed to production.
4) Production Release
The end loop of the pipeline achieves the intended results: the live application has been updated with verified and validated code that meets specifications, and the product feature is available for release. The timeline of the release will depend on other business decisions, but if the CD pipeline is working like it should, the latest features are always tested and production-ready.
What a Successful Continuous Delivery Pipeline Looks Like
A successful CD pipeline identifies code errors and fixes broken builds immediately. Source code cannot pass through stages of the pipeline until all tests have been completed and requirements of the specifications met.
Stages of a CD pipeline should be visible to all team members at all times. When a problem occurs, team members are notified and work together to solve it.
Other traits of a successful CD pipeline include:
- A build is tested one at a time.
- When code does not pass acceptance testing, developers decide if it is a code error, a problem with the test, or an intentional change in the behavior of the application.
- Code deemed not worthy is removed.
- Revised source code is checked-in and moved through the pipeline starting at Stage 1: Commit.
- Prevents compound errors by testing the smallest parts of an application (units) before integrating with other parts.
- Promotes quality builds leading to quality applications with superior functioning.
Making the CD Pipeline Work For You
Developing and using a CD pipeline enables rapid release of new software application features and provides continuous value for the end user. The key is to monitor the pipeline and fix any issues with the automation process that may arise so it is always ready for the next build.
For more tips on making a CD pipeline for DevOps teams, read our best practices for Continuous Delivery.