A CI/CD pipeline aims to mitigate the risks involved in releasing the software into production. However, its efficiency relies heavily on test automation, so achieving success with DevOps stands or falls with how well the development department works with automation and which tools are at their disposal.
One of the main responsibilities of DevOps managers is to support the creation of a release pipeline, which is the route a piece of code or feature must travel from a developer’s local computer into production.
There are different best practices to apply in the building of the pipeline: Continuous Delivery, Continuous Deployment, Continuous Integration, and more. Nevertheless, when creating the ideal release pipeline, you should make sure that it will:
Watch on-demand webinar: Continuous Testing in Agile and Continuous Delivery Environments
With the right approach, it is possible to build such a pipeline. This blog post outlines a DevOps method of color-coding the various stages of the release pipeline, while the next section identifies five critical points of the pipeline where automation can significantly boost productivity, agility, and product quality.
A standard release pipeline consists of the main elements or environments listed below. Depending on the software and compliance requirements, environments might be added or removed from the pipeline, either permanently or by demand.
Related Reading: CI/CD and Continuous Testing: What, Why and How
A release pipeline ensures that no code slips into the production environment (4) without being exposed by the so-called ‘gates’. A gate is a set of requirements that must be met for a build (a piece of code) to pass to the next stage, or environment, of the pipeline. For example, a gate could set the following requirements:
In the following, all stages and gates of the CD release pipeline are color-coded to make it very easy to identify and understand the flows and checks of the process:
This environment is the local PCs of the individual developer. This is where the code is produced and added to the source control system. The piece of code can be a new feature or module to the product, or it can be a fix or change to some existing code.
Related reading: How to Automate Functional UI Tests in a DevOps World
This is where the code is built on a build server and deployed to a CI server.
Test environment gate
After development, the code is ‘checked in’ at the Purple Gate. To pass this gate, the following requirements must be met:
The checks of the Purple Gate are very critical because the Development environment is designed to imitate the Production environment. This means, if the code works in Development, it is likely to work in Production.
More requirements can be added to the Purple Gate. In any case, if any of the checks fail, the check-in should be rolled back and the move to Test should be cancelled.
This environment is for product tests of all kinds. It can contain multiple server setups to accommodate for various test types: functional tests, performance tests, load tests, etc.
Preproduction gate
To pass this gate, the following requirements must be met:
Again, more requirements can be added to this gate. If any of the checks fail, the check-in should be rolled back and the move to Production should be cancelled.
This is where the final software is produced. There is no specific gate following this stage, but there are still checks associated with this final step: Smoke testing is for identifying any bugs before the end-user does. Obviously, this improves the end-user experience as the product is better received.
Do you want to learn more about how to ensure rapid feedback across the CI/CD pipeline through shared automation ownership? Then download the whitepaper on DevOps and Test Automation.
.svg "Leapwork")
