The LEAP

Automation insights and productivity tips from LEAPWORK.

All Posts

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 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

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.

Related Reading: CI/CD and Continuous Testing: What, Why and How

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

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

Related reading: How to Automate Functional UI Tests in a DevOps World

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:

release_pipleline_example

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.

 

DEVELOPMENT

This is where the code is built on a build server and deployed to a CI server.

Purple 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.

Blue 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:

download devops whitepaper

Lucia Cavero-Baptista
Lucia Cavero-Baptista
Content Marketing Manager

Related Posts

How to Overcome Challenges in Cross-Platform Testing

With more businesses on the web, or moving to the web, it’s not often you see new desktop application releases. But the fact remains - many companies rely on a complicated web of desktop applications, web applications and legacy systems to perform business critical processes.

AI in Test Automation: 4 Types of AI that you’ll come across in 2021

AI has, once again, been mentioned as a key technology trend for the year ahead. But what does this mean for test automation? In this post, we break down key terms and explain how QA can benefit from these technologies in 2021 and onwards.

How to Automate Mobile Web Testing with Codeless Selenium

With brick and mortar stores closed during an on-going pandemic, websites, especially e-commerce websites, have to focus more than ever on creating quality customer experiences online. This has created a need for faster testing and new website functionality.