CI/CD Pipeline with Jenkins & GitOps Delivery with Argo CD

Project Overview

I built and validated a software delivery workflow that separates continuous integration from Kubernetes delivery. Jenkins handled source checkout, automated testing, container image creation, Amazon ECR publication and GitOps release updates. Argo CD handled reconciliation between Git-defined desired state and the Kubernetes environments.

This architecture kept Git as the deployment source of truth instead of turning Jenkins into a long-term Kubernetes deployment controller.

Engineering Problem

The application needed a delivery process that could move one tested release through multiple Kubernetes environments without relying on mutable image tags, undocumented manual deployments or a CI server directly controlling long-term cluster state.

• Stop failed application tests before image publication and promotion.
• Create a traceable link between source, CI execution, container image and deployed release.
• Keep application source separate from Kubernetes desired state.
• Promote the same immutable release through development, staging and production-style states.
• Keep Kubernetes reconciliation owned by Argo CD instead of Jenkins.
• Require an explicit approval boundary before the production-style promotion.
• Keep Git and AWS credentials outside source code and the Jenkinsfile.

Delivery Architecture

The delivery workflow is divided into two responsibility planes. Jenkins produces the release and records deployment intent in Git. Argo CD observes that desired state and reconciles Kubernetes toward it.

GitHub
  ↓
Jenkins
  ├── automated tests
  ├── Docker image builds
  ├── Amazon ECR publication
  └── GitOps release update
          ↓
      Git repository
          ↓
        Argo CD
          ↓
Dev → Staging → Production-style
          ↓
     Amazon EKS

What I Built

• Jenkins pipeline cloud-app-ci-pipeline for application integration and release automation.
• Automated application testing before image publication.
• Separate Docker image builds for frontend, API, authentication and worker services.
• Private Amazon ECR publication using build-specific immutable tags.
• A separate GitOps repository containing environment desired state.
• Git-based release updates for development, staging and production-style environments.
• Argo CD applications with automated synchronization, pruning and self-healing.
• A manual approval boundary before the production-style GitOps update.
• End-to-end release verification against the Kubernetes application environments.

CI & Artifact Strategy

Jenkins treated automated tests as a release gate. Container images were built and published only after the application validation stage succeeded.

Jenkins responsibilities

source checkout
      ↓
automated tests
      ↓
container builds
      ↓
Amazon ECR publish
      ↓
GitOps version update

Release artifacts used the Jenkins build number rather than a floating latest reference. The validated release was build-14.

Release: build-14

frontend  → build-14
api       → build-14
auth      → build-14
worker    → build-14

This created a stable artifact identity that could be followed from the Jenkins execution into Amazon ECR, the GitOps repository and the Kubernetes workload configuration.

GitOps & Promotion

Kubernetes desired state was maintained separately from application source in cloud-platform-gitops. Jenkins recorded a new release by changing the version-controlled environment state, while Argo CD remained responsible for applying that desired state to Kubernetes.

• platform-dev reconciled the development configuration into namespace platform.
• platform-staging reconciled staging state into platform-staging.
• platform-prod reconciled the production-style state into platform-prod.
• Automated synchronization, pruning and self-healing were configured for the Argo CD-managed applications.

The same build-14 release was promoted through all three stages. Each promotion was represented by a separate Git commit:

The Git history therefore provided a concrete release trail instead of relying on undocumented manual changes inside the cluster.

Challenges & How I Addressed Them

CI and Kubernetes Delivery Needed Different Owners

Allowing Jenkins to build software and also become the long-term controller of Kubernetes state would tightly couple the CI server to the cluster. I kept Jenkins responsible for producing release intent in Git and used Argo CD as the reconciliation layer.

Mutable Image References Would Weaken Release Traceability

A floating image tag could point to different image content over time. I used Jenkins build-number tags so the same release identifier remained visible across CI, ECR, GitOps configuration and Kubernetes.

Environment Promotion Needed to Preserve One Release Identity

Rebuilding an application separately for each environment could produce different artifacts. Instead, the validated workflow promoted the same immutable build-14 release through development, staging and the production-style state.

Production-Style Promotion Needed a Deliberate Control Point

Fully automatic production-style promotion would remove the opportunity to validate staging before changing the final environment state. I introduced an approval boundary before Jenkins wrote the production-style GitOps update.

Deployment Drift Needed a Defined Reconciliation Path

Git remained the authoritative record of desired deployment state. Argo CD compared that state with Kubernetes and provided synchronization, pruning and self-healing behavior rather than leaving manual cluster changes as the permanent source of truth.

Security Controls

• Git and AWS access were stored in Jenkins Credentials rather than embedded directly in the Jenkinsfile or application source.
• Credential values were not exposed in repository content or portfolio evidence.
• Application source and Kubernetes desired state were maintained in separate repositories.
• Jenkins updated Git instead of containing direct application-deployment logic for Kubernetes.
• Immutable build tags reduced ambiguity around which container artifact was promoted.
• The production-style release required an explicit approval before its GitOps state was changed.

Verified Release Evidence

The delivery architecture was validated with Jenkins build #14 against application commit be00a0c (Add Prometheus metrics to API).

Application commit       be00a0c
Jenkins build            #14

Automated tests          PASS
Frontend image           build-14
API image                build-14
Auth image               build-14
Worker image             build-14

Dev GitOps commit        b98fa50
Staging GitOps commit    689a0f8
Production-style commit  5ce567b

Production-style approval APPROVED
Pipeline result          SUCCESS

After promotion, development, staging and the production-style environment were verified against the same build-14 release. This validated the path from application source through Jenkins, Amazon ECR, Git promotion, Argo CD reconciliation and Kubernetes runtime state.

The temporary AWS environment was later intentionally decommissioned after implementation evidence was captured, so these results describe the validated delivery state rather than claiming the EKS runtime remains permanently online.

Production Considerations

The portfolio workflow demonstrates immutable artifacts, GitOps reconciliation, controlled multi-stage promotion, credential separation and a production approval boundary. For a larger production delivery organization I would extend it with:

• Ephemeral Jenkins build agents for stronger build isolation and horizontal scaling.
• Automated SAST, dependency, Infrastructure as Code and container-image security scanning.
• Signed container images with admission-time verification.
• Protected branches or pull-request approval policies around production GitOps changes.
• External secrets management and short-lived workload credentials.
• Automated integration and end-to-end validation gates before production promotion.
• Deployment notifications and integration with incident-management workflows.

Source Code & Evidence

The delivery implementation is maintained across separate repositories so application integration and Kubernetes desired state remain independently auditable.

• Application & CI Repository — application services, tests, Docker build definitions and Jenkins pipeline configuration.
• GitOps Repository — Kubernetes desired state for development, staging and production-style promotion plus Argo CD-managed platform configuration.

Verified Release Trace

Application source
  be00a0c
      ↓
Jenkins
  build #14
      ↓
Amazon ECR
  4 immutable build-14 images
      ↓
GitOps
  dev      b98fa50
  staging  689a0f8
  prod     5ce567b
      ↓
Argo CD
  sync / prune / self-heal
      ↓
Amazon EKS
  build-14 validated through all stages

Engineering Value

This project demonstrates how I connect CI, artifact management and GitOps without blurring their responsibilities. Jenkins produced tested, immutable releases and recorded deployment intent, while Argo CD remained responsible for Kubernetes reconciliation.

It also demonstrates release traceability and operational control: one source revision can be followed through Jenkins build #14, four immutable ECR artifacts, environment-specific Git commits, an approval boundary and the final Kubernetes validation. That provides a clear evidence trail when comparing environments, troubleshooting releases or planning rollback.