GitOps with Argo CD / Flux

Git as the source of truth for deploys.

Traditional CD has the pipeline push to production — the CI job holds cluster credentials and runs kubectl apply or helm upgrade. GitOps inverts that: the desired state of production lives in a Git repository, and an in-cluster agent (Argo CD or Flux) continuously pulls that repo and reconciles the cluster to match it. You do not deploy by pushing; you deploy by merging a change to the state repo, and the agent makes it so.

Why GitOps is more secure

The security wins are structural. The CI pipeline no longer needs production cluster credentials — it only writes to a Git repo, so a compromised pipeline cannot directly touch the cluster. Every change to production is a Git commit: reviewed, attributed, and auditable, with no out-of-band kubectl. And because Git is the declared source of truth, drift is detected automatically — if someone hand-edits the cluster, the agent notices the divergence and can revert it. Production becomes exactly, and only, what is in the repo.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata: { name: payments, namespace: argocd }
spec:
  source:
    repoURL: https://gitlab.acme.internal/acme/deploy.git   # the state repo
    path: payments/
    targetRevision: main
  destination: { server: https://kubernetes.default.svc, namespace: payments }
  syncPolicy:
    automated: { prune: true, selfHeal: true }   # revert drift back to Git

How CI and GitOps meet

The handoff is clean: CI builds, scans, and signs the image, then its final step is to open a commit or merge request against the state repo bumping the image digest. That MR is reviewed (and its image signature can be verified as a gate), and on merge Argo CD/Flux rolls it out. The image tag/digest in Git is the single record of what is deployed — which is also what makes rollback trivial, as the next lessons show.