How to Create a DevOps CI/CD Pipeline (With Example)

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:

• Increase product quality
• Increase the agility of the product’s development
• Reduce the stress and last-minute panic associated with product releases

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.

Standard Elements of a CI/CD Pipeline

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.

1. Local development environments; the individual developers’ personal computers
2. A Continuous Integration (CI) server, or development server
3. Test servers for functional UI testing of the product
4. A production environment

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:

• The code should build without errors
• All unit tests must pass
• All functional UI tests must pass

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:

Local development

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

Development

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 code can build.
• The code must have passed all unit tests.
• The code must have passed a local verification by the individual developer.

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.

Test

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:

• The code must have passed all automated functional UI tests (regression testing)
• The product must have passed a verification of its visual appearance
• The server log files must have been inspected after regression tests
• Performance data must have met an acceptable benchmark

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.

Production

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.

Download Whitepaper: DevOps and Test Automation

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.