How a manual intervention pipeline restricts deployment

It is important to consider multiple factors when deploying production code. Later on, we will deploy, such as securing permission, pulling requests, testing the robustness of the application, and making sure it is tested thoroughly. Deployments will occur in the production cluster after a manual intervention step is added for management approval.

The advantages of manual intervention are avoiding accidental deployments and achieving governance over the production environment and security. Our goal in this article is to create a manual intervention pipeline. In the middle of the pipeline are the CI and CD.

We are creating a series of articles about complete CI/CD pipelines on the Red Hat OpenShift Container Platform using Jenkins and Red Hat Ansible Automation Platform. This 3-part series will cover the following topics:

• Part 1: Continuous Integration with Jenkins on OpenShift
• Part 2: Continuous Deployment using Ansible Automation Platform on OpenShift
• Part 3:  Restricting a production deployment on OpenShift with Jenkins and Ansible

An overview of the architecture and workflow

This article is the third installment of the series. Assuming you have already read the previous articles on continuous integration and continuous deployment, proceed with the demonstration.

The architecture diagram in Figure 1 illustrates the multiple clusters we will use in this demonstration. Adding manual intervention in CI/CD flow restricts the deployment on production. The purple line represents the production workflow. The workflow triggers when the release manager logs in to the Jenkins dashboard and clicks on approval. Then the Ansible Automation Platform triggers and fetches the playbooks from Git to do the deployment on the production cluster using the token and certificate of that cluster.

Add manual intervention stage in Jenkins

We have to create a new pipeline in Jenkins where we define the conditional input. The production deployment happens when the release manager selects the proceed.

For more secure and restricted access, restrict the other Jenkins users on the dashboard.

For production deployment, please follow these steps:

• Make sure you have a second OpenShift cluster.
• In the Ansible Automation Platform, create another template for deployment. Fill in the details for credentials, inventory, and template creation.
• Login to Jenkins dashboard.
• Create another pipeline.

node {
   stage 'Checkout'
   // Get some code from the repository
   stage 'Build'
   // Run the build
}

stage 'deployment'
input 'Do you approve deployment?'
node {
    //deploy things
}

• In the build trigger, select after other projects and add the CI pipeline name.
• Create a new CD approval stage for production deployment. 
• Add an approval stage for that select other projects to be built.
• Select Build Now. The pipeline will do the job as shown in Figure 2.
• Click Proceed to start the CD approval pipeline of production.

Click on the ↗ icon to play the racing game (Figure 3).

Enjoy the game (Figure 4).

How to get more practice

This concludes the series covering the continuous integration on OpenShift using Jenkins and continuous deployment using the Ansible Automation Platform on OpenShift. Check out a demo of this project in DevNation2022.

Explore our interactive labs for OpenShift and Ansible Automation Platform to get hands-on practice. If you have questions, feel free to comment below. We welcome your feedback.