CI/CD

CI/CD: Implement your ideas into production

By HiFX Engg. Team | April 28, 2021 | 5 min read

A case study where we implemented CI/CD with Kubernetes.

Continuous building, testing and delivery of iterative codes increases the speed of the Software Development Lifecycle (SDLC), i.e., when a developer writes a code, it is automatically deployed to the respective environments enabling them to test the functionality themselves, and submit the build to the testing team for an elaborated testing. Notably, with the advent of a new release the entire process recurs.

There are three primary steps involved in continuous software development, i.e., from the source code to production:

• Continuous Integration (CI)
• Continuous Deployment (CD)
• Continuous Delivery (CD)

The orchestration of various steps including building, packaging, testing, and the deployment of the validated codes into the appropriate environments defines the CI/CD pipeline. The systematic layout of a CI/CD pipeline provides the team a wider comprehension of the processes involved in carrying their ideas into production. The CI/CD pipeline is often driven by environments, tests, people, services, and outcomes. The main goal of the DevOps team is to automate CI/CD in their development environment.

The software’s employed in an automated CI/CD include the following:

• Gitlab
• Jenkins
• Docker
• Helm
• Tiller
• SonarQube
• Anchore

Continuous Integration

Multiple code changes, additional new features and daily iterations in the code repository, along with the creation of scripts, for an uninterrupted automatic building and packaging of the codes is referred to as Continuous Integration. The packaging procedures are different for various systems, such as, a JAR file is produced for the JAVA build, which is then deployed as a docker image. The scripts ensure minimal errors, and the testing phase ascertains keen check on the guidelines and standards set for each application.

The most enticing part of CI is the achievement to integrate new ideas into an application. Further, CI strives to make its builds repeatable, consistent, errorless, and scalable through integration tests and unit tests. However, there are challenges faced during CI, such as overburdening of the CI platforms, which can be avoided by being strategic in the application of the test suit

Continuous Deployment

Continuous deployment involves the installation and distribution of the codes, and focuses on the automated path with least resistance to get the package into the required environments. In other words, continuous deployment ensures the automated deployment of artefacts from CI into the appropriate environments. Modern technologies, such as Kubernetes, may only have a namespace that separates the environments.

Continuous Delivery

The difference between continuous deployment and continuous delivery is that, along with the continuous code changes the deployments are made manually in continuous delivery, whereas the deployment is fully automated in continuous deployment. The components that constitute a CD pipeline include the version control system, the CI system, the docker registry that stores the docker images, and the Kubernetes cluster. Automation of all the aforesaid components ensures a smooth and seamless delivery.

CI/CD in Kubernetes

Kubernetes is known for its efficiency and wide utilization, such as deployment of applications, scheduling of batch jobs, handling of workloads, and other rollouts, in the cloud world. The primary use case of Kubernetes is identified as its ability to run CI/CD pipelines.

Integration of various elements in a pipeline involving heterogenous teams or applications can be distressing. However, contemporary CI/CD tools have come to the rescue enhancing the flexibility and robustness of the pipelines. An example of a disparate application is one that has serverless pieces. In such an instance, the workloads requiring longer time are deployed to Kubernetes followed by the deployment of the serverless portion to a cloud provider. Jenkins, Spinnaker, Drone, and GoCD are some of the CI/CD platforms used by Kubernetes.

Kubernetes for CI/CD Use Case

The Jenkins is used in this project, as its widely used and is known for its extensibility and huge ecosystem. JenkinsX is the official plugin that is recommended while using Kubernetes due to its special features, such as automated CI/CD, GitOps, and preview environments. The following order of installation needs to be maintained before installing JenkinsX on Kubernetes:

• Installation of Helm: the package manager for Kubernetes
• nstallation of Tiller for the smooth functioning of Helm
• heck the configuration values of deployment by running the inspect command
• Careful inspection followed by installation of JenkinsX

A real-time project that depicts the stack deployment process using Kubernetes is summarized below.

Tagging the Build

When the code is ready to be deployed, it is tagged using a particular format. Something like stag-frontend-x.x.x. A push event is set in Gitlab, which triggers a Jenkins job. The Jenkins Server reads the ‘Jenkinsfile’ at the root of Git Repository and follows the instructions written in it.

The Jenkins’ Job

The ‘Jenkinsfile’, which instructs the applications concerning the build, test, docker, publishment, and delivery, is written in Groovy language. Before the code is even packed into a docker image, the dependencies are pulled using the Jenkinsfile.

The steps involved in a real-time project along with its image have been described below:

• Identification of the tag. For example, if the tag starts with stag-x.x.x deployment will be to the staging environment, whereas the tag prod-x.x.x contains its own set of instructions. The Jenkins job ends when the format is not met.
• Now the code will be subjected for static code analysis with the help of an open-source project SonarQube, which checks the codes for potential errors and poor coding practices.
• The docker image will be built following successful quality check of the code.
• Another open-source project named, Anchore, is used in this project to analyze docker images. Anchore evaluates security, compliance and enforcement checks.
• The docker image is then pushed to Elastic Container Registry (ECR)
• The deployment tool used in this project is Helm chart, as it manages the most complex Kubernetes application. Specifically, the Umbrella chart version of the Helm chart, which includes a root chart that has multiple subcharts, is employed in this project. During deployment, the tag/version of the subchart application along with the corresponding version in the root charts ‘requirements.yaml’ file needs to be updated. All these procedures are handled via Groovy script in Jenkins file.
• Finally, the deployment is initiated using ‘Helm Package Manager’ with the container orchestrator.
• The deployment is followed by the cleaning up of docker images that are older than two weeks

Operation of CI/CD on Kubernetes At Scale

Some of the significant points to be kept in mind for the CIC/CD on Kubernetes to function at scale are mentioned below:

• Preference of Kubernetes Distribution, such as Managed Kubernetes Solution
• Preference of Docker registry and package management, such as Helm
• Utilization of integration flows, such as ChatOps and GitOps