Complete CI/CD Setup with GitOps Approach part-1

Ever wondered what this buzzing word “CI/CD” really means? If you Google it, you’ll find some fancy definitions—some understandable, some confusing. At its core, it’s just two things:

• CI (Continuous Integration): Integrating code and building software.

• CD (Continuous Deployment/Delivery): Delivering that software to users.

This understanding is good as a start, but I always had questions:

How does Jenkins do all of this automatically? Don’t people have to manually build, test, and deploy?

That curiosity led me to explore CI/CD deeply during my DevOps workshop. In this blog, we’ll go end-to-end in two parts:

• Part 1: Theory

• Part 2: Implementation

What is CI/CD?

Let’s break it down without the fancy definitions:

• Continuous Integration (CI):
  After writing code, we build the software. We also ensure it’s free of errors and security vulnerabilities by running tests and static code analysis.

• Continuous Deployment (CD):
  Once the software (binary) is ready, we deploy it so customers can access it.

Whenever a code commit is triggered, this entire process happens automatically—hence the terms continuous integration and continuous deployment.

Modern CI/CD: Containerization & Kubernetes

Nowadays, applications are containerized and deployed to Kubernetes.

• Docker → For containerizing the application

• Kubernetes (K8s) → For deployment and orchestration

In this blog, I’ll focus on:

• CI using Jenkins

• CD using GitOps

CI Process with Jenkins

1. Source Code Repository:
   We use GitHub for storing a simple Java application.

2. Triggering the Pipeline:

   • Configure webhooks in GitHub.

   • Whenever a commit or pull request occurs, the webhook notifies Jenkins to trigger the pipeline.

3. Pipeline Structure:

   • We use a declarative pipeline, which is easy to write and collaborate on.

   • Stages in the pipeline:

     • Build: Using Maven (configured either in Jenkins or as a Docker agent).

     • Code Quality & Security: Using SonarQube for static code analysis (SAST). Optional: add regression or functional tests.

     • Notifications: Configure email or Slack notifications if the build fails or vulnerabilities are detected.

     • Docker Image Creation: Use a Dockerfile to build the image and push it to a container registry.

     • Push Changes to Application Manifests: Using a shell script, we update the application manifest (like the Docker image version) in a Git repository.

This completes the CI process.

CD Process with GitOps

In traditional CI/CD:

• Application manifests (like deployment.yaml, service.yaml) are often hardcoded in the Jenkins pipeline.

  Problem 1: If you want to add a volume or make other manifest changes, it won’t trigger the pipeline because CI pipelines are triggered only by source code changes.

  Problem 2: To make changes someone have to manually login to cluster, it’s not a good practice: there’s no auditing, no review, and it’s hard to reproduce environments.

• Problem 3: If manifests not hardcoded, any change triggers the entire pipeline, even if the application code hasn’t changed.

✅ Key point: Hardcoding manifests or managing them improperly in the pipeline can lead to unnecessary builds or unsafe manual edits.

GitOps Solution

• Maintain a separate Git repository for application manifests.

• Use a GitOps controller like ArgoCD, which continuously monitors this repo.

• When a change occurs in the manifest (pushed via the CI shell script):

  • ArgoCD automatically applies the change to the cluster.

  • The controller maintains the state between Git and the cluster, overriding any manual edits.

• Benefits:

  • Manifest changes do not trigger the CI pipeline unnecessarily.

  • Cluster state is always in sync with Git.

  • Changes are auditable, version-controlled, and safer.

CD Process

After the image is updated in the GitOps repo, ArgoCD, being a Kubernetes controller deployed inside the cluster, will:

• Continuously watch the cluster.

• Detect the new image version in the manifest.

• Deploy the updated image inside the cluster automatically.

• Maintain a synchronized state between the Git repository and the cluster, overriding any manual changes to ensure consistency.

  

Summary:

• CI/CD automates building, testing, and deployment of software.

• Jenkins handles CI efficiently using pipelines, webhooks, and Docker.

• Shell scripts in CI can push changes to application manifests without triggering unnecessary builds.

• GitOps with ArgoCD handles CD by syncing manifests from Git to Kubernetes, maintaining cluster state, and enabling auditability.

Stay tuned for Part 2, where we’ll implement this complete CI/CD pipeline hands-on!

Hope you like it :)