Streamlining Continuous Deployment

A Comprehensive Walkthrough

Published in

Nerd For Tech

5 min readFeb 11, 2024

In the realm of software development, an efficient and systematic approach to continuous integration and deployment is crucial for maintaining a robust development lifecycle. This article delves into the meticulous steps involved in the deployment process after completing a code iteration, illustrating how a seamless workflow can enhance collaboration and reliability.

Tagging the Code

Upon completing a coding milestone, the first step is to tag the code in the version control system, in this case, Bitbucket. Tagging provides a snapshot of the codebase at a specific point in time, aiding in traceability and versioning. The tag, such as ‘4.1.18.0,’ follows a logical sequence, incrementing from the previous tag (‘4.1.17.0’). This versioning system ensures clarity about the evolution of the codebase.

Triggering a Build

The build process is initiated with carefully selected parameters, including the project, service name, Java version, and PomVersion.

Java version defaults to 8 but can be customized, accommodating diverse project requirements. The GitTag parameter specifies the tagged version (‘4.1.18.0’), enabling the build system to fetch the corresponding code snapshot. The InitTag is optional.

If your Java version is 17, fill the version like below. In my case it was 17-corretto

Jenkins Build Status Check

Jenkins, a popular automation server, takes center stage in the continuous integration pipeline. After triggering the build, developers monitor Jenkins for real-time status updates. This step is crucial for identifying potential issues early in the development process, allowing rapid resolution and preventing the propagation of errors.

Updating Kubernetes Yaml in Bitbucket

Following a successful build, attention shifts to Bitbucket’s dedicated repository for Kubernetes configurations. Within the Kubernetes Yaml repository, the Kustomization directory houses essential configuration files, notably ‘kustomization.yaml’ and ‘replica-count.yaml.’ Developers modify ‘kustomization.yaml’ with the GitTag (‘4.1.18.0’) to ensure that the deployed environment aligns with the tagged code version.

apiVersion: Indicates the version of the Kustomize API being used.
kind: Specifies the kind of Kustomization resource.
bases: Refers to the base directory or directories containing the Kubernetes resource files that will be customized.
patchesStrategicMerge: Lists YAML files relative to the current directory that contain patches to be applied to the base resources. In this case, replica-count.yaml is one such patch file.
images: Specifies the container images and their new tags to be used. It's a way to manage and update image references in the Kubernetes manifests.

For example, the first image refers to xxxxxxxxxx/xxxxxxx with a new tag 4.1.32.0.
The second image is for xxxxxxxx/xxxxxxx with a new tag V1.0.0.47.

This configuration file is essentially instructing Kubernetes how to customize and deploy resources by specifying base resources, patches, and updated container image tags. The replica-count.yaml patch, for instance, likely contains instructions to modify the replica count of a particular resource.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: xoxoxoxo
  namespace: xoxoxoxo
spec:
  replicas: 2

The replica-count.yaml file is a Kubernetes resource manifest written in YAML format, specifically targeting a Deployment resource.

apiVersion: Specifies the API version for the Kubernetes resource. In this case, it is using the apps/v1 API version, which is common for Deployment resources.
kind: Defines the type of Kubernetes resource. Here, it is a Deployment.
metadata: Contains metadata about the resource, such as its name and the namespace in which it is located.

name: Specifies the name of the Deployment as "xoxoxoxo"
namespace: Indicates the namespace in which the Deployment is located, set to "xoxoxoxo"

4. spec: Describes the desired state for the Deployment, including the number of replicas.

replicas: 2: Specifies that the desired number of replicas for the xoxoxoxo Deployment in the xoxoxoxo namespace is set to 2. This means Kubernetes should maintain two identical instances (pods) of the specified workload.

In summary, this Deployment manifest is instructing Kubernetes to create and manage two replicas of the workload named xoxoxoxo in the xoxoxoxo namespace. The number of replicas can be adjusted based on the specific needs and scaling requirements of the application.

Automatic Deployment with Kustomization

The modified ‘kustomization.yaml’ serves as a blueprint for deployment, encapsulating essential configuration details. Committing the changes triggers an automated deployment, eliminating manual intervention and reducing the risk of human error. This streamlined approach aligns with the principles of Infrastructure as Code (IaC), enhancing consistency across different environments.

Verification through ArgoCD

To ensure the successful deployment of the tagged code, developers leverage ArgoCD, a declarative, GitOps continuous delivery tool for Kubernetes. Checking the deployment status in ArgoCD provides a high-level overview of the environment’s health, allowing for quick identification and resolution of potential issues.

In summary, each step in this deployment process plays a critical role in maintaining a reliable, reproducible, and automated workflow. From meticulous code tagging to automated deployment with Kustomization and verification via ArgoCD, these steps collectively contribute to a streamlined and efficient continuous deployment pipeline. By embracing these practices, development teams can ensure the rapid and reliable delivery of software, meeting the demands of modern agile development.

I found a post on LinkedIn that will add more value to what you have learned so far.

A Visual Guide to CI/CD | Image by Sahn Lam

Hope you learned something new.❤️

Connect with me via;