Here is the example pipeline we will talk about at a high level. It is entirely up to the process that you want to implement in your organization, this is just one example.

Open

In this pipeline, we will have 4 roles that make up our team.

Open

High-Level Approach

Here's the high-level approach for the pipeline. In the following sections, we will see a screenshot for each Gate and Step configured.

• There are 4 stages - Development, Test, QA, and Production.

• Development stage does not have any Gates, so all projects will deploy right away when a new Snapshot is created.

• Run various types of tests in each Stage and check for results in the next stage.

• Test environment is based on Schedule, but QA is based on approval by the QA team to make sure they are ready to accept new code.

• All steps in the pipeline are automated except for a Manual Step in the QA stage to perform some Manual tests.

• Production environment has Approval as well as Schedule Gates. The weekend schedule configured allows for automated deployments during non-business hours.

• Deploy All Step will notify the appropriate team in case of a failure in each Stage.

Stages

Development

We are not using any Gates in the Development environment to allow for continuous deployment into that environment. Developers can set up a Project Trigger on Projects to allow for build and deploy in a continuous manner.

The steps used are for Deploying All Projects and Test All to execute Unit Tests after deployment. Deploy All Step will deploy all projects in Release as per Deploy Priority setup on Release, which will allow for Sequenced deployments.

Test

The first thing we want to do is to check for tests executed in Development environment and continue only if the tests were successful. Then we will use Schedule Gate to automatically deploy at Noon every day. This option allows us to deploy to the Test environment at a predefined time and it will take the latest Snapshot successfully deployed in Development environment.

The steps used are for Deploying All Projects and Test All to execute Integration Tests. Deploy All Step will deploy all projects in Release as per Deploy Priority setup on Release, which will allow for Sequenced deployments.

QA

The first thing we want to do is to check for Tests executed in Test environment and move on only if the tests were successful. Then we will use the Approval Gate with the QA role, allowing the QA team to control the promotion of code to the QA environment as per their testing schedule.

The steps used are for Deploying All Projects and Test All to execute Functional Tests. Deploy All Step will deploy all projects in Release as per Deploy Priority setup on Release, which will allow for Sequenced deployments. Additionally, we will use Manual Step to allow for some manual verification in the QA environment.

Production

The first thing we want to do is to check for Tests executed in the QA environment and move on only if the tests were successful. Then we will use the external ServiceNow Approval Gate overridable by the Operator role, so that allows Operators to control promotion of code in the Production environment if needed. Otherwise, it will be governed by a ServiceNow ticket. Next, we will have Schedule Gate to run steps only on Saturday at 9 PM which would allow for code promotion at predefined downtime.

The steps used are for Deploying All Projects and Test All to execute Smoke Tests. Deploy All Step will deploy all projects in Release as per Deploy Priority setup on Release, which will allow for Sequenced deployments. We will only run simple verification tests (aka Smoke Tests). Additionally, we will use Utility Step to allow for sending a Slack message to Operators. This could easily be a notification step as well to send an email instead.