CI/CD & GitOps

Imagine managing a high-stakes deployment for a tier-1 service. In the traditional CI/CD paradigm, a CI server (like Jenkins) would build an artifact and then proactively “push” the deployment via an imperative script: ssh user@server "docker pull my-app && docker restart my-app"

In the world of Kubernetes, this “push” model is a recipe for disaster. If you run kubectl apply -f deploy.yaml from your laptop, someone else applies a hotfix, and CI runs an older pipeline, you trigger “Configuration Drift”—the cluster state diverges from what you think it is, leading to untraceable outages. Who really knows what is running in the cluster?

[!IMPORTANT] Enter GitOps. GitOps is a set of practices where Git acts as the single, indisputable source of truth for your system’s desired state. Instead of external systems pushing changes, an agent (like ArgoCD or Flux) runs inside the cluster, acting in a “pull” model. It continuously monitors Git and reconciles the cluster state to exactly match the repository.

1. The GitOps Workflow

Let’s break down the anatomy of a GitOps pipeline:

  1. Developer: Commits code changes to the application repository.
  2. Continuous Integration (CI): A tool like GitHub Actions or GitLab CI builds the Docker image, runs tests, and pushes the immutable artifact to a Container Registry.
  3. Config Update: The CI pipeline updates the deployment.yaml in a separate Configuration Repository (Config Repo) with the new image tag.
  4. Reconciliation Loop: The GitOps agent (ArgoCD) detects the drift between the Config Repo and the live cluster.
  5. Sync: ArgoCD autonomously applies the new manifest to the cluster, ensuring synchronization.

2. Interactive: GitOps Sync Visualizer

Simulate a GitOps workflow. Change the Git State and watch the Cluster State catch up.

🐙

Git Repository

replicas: 3
→
Synced
☸️

Kubernetes Cluster

3. Defining an Application in ArgoCD

ArgoCD uses a Custom Resource called Application to define the sync.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/my-org/my-app-config.git
    targetRevision: HEAD
    path: k8s/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
  • repoURL: Where is the YAML?
  • path: Which folder?
  • destination: Which cluster?
  • syncPolicy: Should it auto-sync? selfHeal means if someone manually deletes a deployment, ArgoCD puts it back immediately.

4. Progressive Delivery (Blue-Green / Canary)

Standard Kubernetes RollingUpdate is basic. You can’t say “Release to 1% of users, check metrics, then rollout to 10%”.

For this, we use Argo Rollouts.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {duration: 1h}
      - setWeight: 40
      - pause: {duration: 1h}
      - setWeight: 60
    ...

This replaces the standard Deployment object and adds traffic splitting capabilities.

5. Summary

  • GitOps: Git is the single source of truth.
  • ArgoCD: The agent that syncs Git to Cluster.
  • Declarative: We don’t script deployments; we declare the end state.
  • Progressive Delivery: Use tools like Argo Rollouts for Canary/Blue-Green deployments.