Stages in CI/CD Pipelines

How pipelines are created to build and test application code and then deploy it to different environments.

Continuous integration (CI) is a software development practice in which all developers merge code changes in a central repository (Git). With CI, each code change (commit) triggers an automated build-and-test stage for the given repo and provides feedback to the developer(s) who made the change.

Continuous delivery (CD) is the practice of automating the entire software release process. CD includes infrastructure provisioning in addition to deployment.

A CI/CD pipeline is a collection of stages, and each stage performs a specific task to achieve some objectives.

Productivity — Code review, unit test, code coverage, code analysis, integration test, and run-time vulnerability are essential stages for design, quality, and security feedback to the developers.

Security — Detect code and component vulnerabilities that are attack surfaces for potential exploitation.

Defect escape — Reduce failure of customer interactions and costly rollback. A new release is typically providing new features or enhancing existing ones. If the features do not provide the correct functionality, the consequence will be customer dissatisfaction and potential revenue loss.

Scalability — Discover scalability issues before the production release. A canary release is a way to deploy the new version to detect scalability issues using production traffic and dependencies.

Time to market — Deliver features to customers quicker.

Reporting — Insight for continuous improvement and metrics for auditability.

GitOps CI

That illustrates a comprehensive CI pipeline building on the GitOps CI/CD.

PRE-BUILD STAGES

• Pull Requests & Code Review — all CI/CD pipelines should always start with a pull request, which allows code review to ensure consistency between design and implementation and catch other potential errors.
• Vulnerability Scan — this might detect known vulnerabilities and licensing issues early in the development cycle.
• Code Analysis

BUILD STAGES

• Build — the build stage typically starts with downloading the dependency libraries before the project source code’s compilation.
• Unit Test — a unit test is for verifying a small piece of code doing what it is supposed to do.
• Code Coverage — code coverage measures the percentage of code that is covered by automated unit tests.
• Docker Build — a Docker image is the deployable unit for Kubernetes.
• Docker Push — the newly built Docker image needs to be published to a Docker registry for Kubernetes to orchestrate the eventual deployment. A Docker registry is a stateless, highly scalable server-side application that stores and lets you distribute Docker images.

CI STAGES

• Git clone Config repository — this stage performs a Git clone to clone the Kubernetes config to the built environment for the subsequent stage to update your manifest.
• Update manifests — once you have the manifests in your build environment, you can update the manifests with the newly created image id using a configuration management tool like `Kustomize`.
• Git commits and push — once the manifests are updated with a new image id, the last step is to commit the manifests back to the Git repo.

POST-BUILD STAGES

CI Metrics

• Build issues
• CI
• Compliance requirements — for SOC2 requirements, build information such as test results, who did the release, and what was released are required to be maintained anywhere from 14 months up to 7 years.
• Build notification

GitOps CD

That illustrates a comprehensive CD pipeline building on the GitOps CI/CD.

CD STAGES

• Git clone Config repository — the GitOps operator detects changes in your repo and performs a Git clone to get your Git repo’s latest manifests.
• Discover manifests — the GitOps Operator also determines any delta between the manifests in Kubernetes versus the latest manifests from the Git repository.
• K8S Apply — if the GitOps operator determines differences between Kubernetes manifests and Git repository manifests, the GitOps operator applies the new manifests to Kubernetes using the kubectl apply command.

POST-DEPLOYMENT STAGES

• Integration tests — integration testing is a type of testing to check if different modules are working correctly together.
• Run-time vulnerability — run-time vulnerabilities are traditionally detected by penetration testing. Penetration testing, or ethical hacking, is the practice of testing a computer system, network, or web application to find security vulnerabilities that an attacker could exploit.
• CD Metrics — Compliance SOC2 requirements: build information such as test results, who did the release, and what was released are required to be maintained anywhere from 14 months up to 7 years.

There we have covered some of the stages in the CI/CD pipeline. From now we can take a look at how the CI/CD pipeline can automate the promotion of code, image, and environment. But it will be for the following article.

Keep us in touch. If and, any questions, please hit me up. Thank you very much.