What are the components of good CICD DevOps Pipeline

What is this for?

Well, it is true that there are already out-of-the-box DevOps CI/CD tools like GitLab. There are those who want to build a custom CI/CD pipeline for enterprise business because of governance, control, and custom processes. In this article, we will discuss the following:

• CI/CD Process Template

• Open-source Technology to build your Custom CI/CD pipeline

• Description of each process and technology used in the pipeline.

This article is not a custom CI/CD pipeline tutorial but describes What are the components of good CICD DevOps to help executive leaders build a solution design for enterprise business. One can use any technology to build a custom CICD pipeline wether that be Jenkins. GitLab, or GitHub. Lets start discussiing the components of good CICD DevOps Pipeline.

Here are the Components of a Good Custom CICD Pipeline for Enterprise Business

We are not claiming that there is only one process for CI/CD that will meet enterprise requirements. There is no single process that can do so. Let us start discussing the CI/CD DevOps delivery process. See the image below.

1. First Step in CICD Pipeline - Code Repository

The first step in the CI/CD pipeline occurs when the code is checked in by the developer into the repository. As soon as the code is checked into the repository, a listener for the code will trigger the next step called Code Scanning.

2. Second Step in CICD Pipeline - Code Scan

Once the code is in the repository, the listener will trigger code scanning. Code scan checks for two things: security vulnerabilities and best practices. These are two different things. A security vulnerability check will inspect things in the code like exposed passwords, security tokens, and some hard-coded parameters that are exploitable. Meanwhile, a code best practices scanner checks for potential bugs in the code such as infinite loops, functions without returns, and unused variables.

The code scan result will be sent via email or chat to the appropriate project stakeholder. You may decide to integrate an automated approval request early on in this process so that approvers may decide on the scan result, whether to proceed or not. Others will simply end the process if an error is detected. Both options will work depending on preference. The completion of this step triggers another process called Code Build.

3. Third Step in CICD Pipeline - Code Build

After completing code scanning, a code build will be triggered. Code build is where code dependencies and configuration are downloaded. An automated code compilation or packaging will be triggered. The output here is to convert the code into a container image. A container image is your binary representation of the container. This is now your release build to be sent in the next step called image scanning.

4. Fourth Step in CICD Pipeline - Image Scanning

Unlike code scanning that checks for static vulnerabilities, image scanning checks for binary vulnerability that potentially deployed to production. An example of binary vulnerabilities are deprecated runtime libraries, and the use of outdated platforms downloaded when image is created.

At this step, an email notification is sent to stakeholder for the result of image scanning. Often, there is an automated approval is where in project team may choose to reject an image if they find a critical or high vulnerability result of the scan. Once image scanning is complete, it goes to the next step called "Image Repository".

5. Fifth Step in CICDP Pipeline - Image Repository

After successfully scanning the container image, the image are sent to image repository. This is where the collection of image releases are being kept. Image that are stored here are called release candidate. Meaning it is a image worth for production deployment and can be used multiple times in the future. Once image is stored in the image repository, next step is triggered which is code deploy.

6. Sixth Step - Code Deploy and Infra as a Code

We only called this code deploy but there is no actual code being deploy here but rather a "final container image" will be sent to the Kubernetes cluster. At the same time, infrastructure as a code is also shipped along with the image. Infra as a Code is an instruction to the Kubernetes cluster on how to provision the necessary infrastructure and dependencies needed by your container image in order to be deployed and run. Thus we call it code deploy. The Infrastructure as a Code is automatically triggered and your container is now deployed. After this step, another process will be triggered called "Kubernetes Process" .

6. Sixth Step - The Kubernetes Runtime

As soon as the infrastructure as a code is executed / run. It launches the container and it becomes a live application in the form of Pods running inside Kubernetes orchestrator. The app becomes available to be accessed by end users / testers / internal users. Often the release goes first to staging environment. An email notification prompting the project team that the release is sent to staging environment, and an e-mail approval is sent seeking permission to deploy in production. Details will be discussed in next step called "email approval".

7. Seventh Step - Final Email Approval

By this time the app is already in staging environment, a request for approval e-mail was also sent. The email may contain "buttons" called Approve | Disapprove. When the project team clicks the approve, the app is automatically deployed to production. The process is same in the code deploy, it becomes now live to public. The purpose of the Disapprove button is that if for some reason project team may cancel the release they will have the capability to do so.

8. Step Eight - Rollback Feature

This is just a nice to have feature. It will be great that after the final approval and the app has been made live to production. Another e-mail notification will be sent called "Automated Rollback". Clicking approve does the rollback, while denny rejects the rollback. This feature allows business to go back to the last working version of the app should in case they are not satisfied with the release.

What are the technologies used in building Custom CICD Pipeline for Enterprise Business?

In this article, we will concentrate on listing open-source technologies that are suitable for constructing a customized CICD pipeline for enterprise applications. While we may touch upon some proprietary tools used for email, approval flow, and chat functions, it's important to note that these are not considered essential DevOps technologies but are nice to have once you have your pipeline in placed. Here are some of the few technology I use in my arsenal:

Important reminder that the entire CICD pipeline is managed and provisioned inside Jenkins. So all of the technology below were integrated via Jenkins through API and Websockets.

1. Code Repository - Repository is where code are stored. Since this is enterprise grade, you may use AWS Code Commit. You need to signup for them though.

2. Code Scanning - For code vulnerability scanning. One may use Data Dog or Sonarqube if on tight budget.

3. Code Build - Building the code is via Jenkins slave and few scripts that you have to do. However; as long as you use Docker File, it should build successfully based on your YAML configuration. Check this blog for building Docker.

4. Image Scanning - Trivy is a very powerful security scanning tool for container image. It is opensource.

5. Image Repository - This is where container image are kept. You may use AWS Container Registry or on our case we hosted our own called Harbor.

6. Code Deploy - This is a combination of Jenkins Scripts, and Jenkins Plugins.

7. Infrastructure as a Code - We love using Helm and Terraform. Both works hand on hand.

8. Kubernetes - We are using AWS EKS. This is an enterprise grade Kubernetes from AWS without licensing cost. Users only pay the infrastructure consumptions.

9. Penetration Testing - As a word of caution, please inform your cloud provider when you are performing this. They may block you and some actions may be illegal. You may use Kali Linux.

10. Automated Approvals - You may use Teams and Power Automate combined, but on our case for cost saving purposes we decided to go for Slack. Slack can be programmed to respond approval request with Jenkins. Note that the approval system are not free.

Teodoro Rico III(Perry):

Teodoro Rico III (Perry) is a technology executive from the Philippines, currently working as a First Vice-President in the financial sector. He is a Cloud Architect, Cloud Infrastructure, and DevSecOps expert, proficient in both strategy, business case, and hands-on experience.