ArgoCD

CI answers “does this build pass.” Deployment is a different question — “what’s actually running where, and does it match what’s declared in Git” — and ArgoCD is the tool I run in production to answer it, reconciling fleets of applications across multiple clusters and environments.

Where it fits

I keep deployment deliberately separate from Jenkins and Concourse: CI tools build and validate an artifact, but they shouldn’t be the thing pushing changes into a live environment. ArgoCD owns “make the cluster match Git,” full stop — nothing else applies changes directly. Moving a validated change between environments is a separate concern, handled by Kargo.

Principles that hold up

• Git is the source of truth, not a trigger. ArgoCD continuously reconciles cluster state against a Git repo rather than applying changes as a one-time push. Drift — someone kubectl edit-ing something by hand — gets detected and can be flagged or auto-corrected, instead of silently persisting until the next deploy overwrites it.
• Sync policies matched to the environment’s risk tolerance. Auto-sync with self-heal is reasonable for a lower environment; production usually deserves a manual sync gate, or at minimum a required approval step, even when everything else is automated.
• App-of-apps or ApplicationSets for anything with more than a few environments. Managing each environment as a hand-maintained ArgoCD Application doesn’t scale past a handful before it becomes its own maintenance burden; generating them from a template does.

Why the split between CI and CD tools matters

Coupling build and deploy into one pipeline tool tends to erode the boundary between “this passed tests” and “this is now live” — a pipeline that both builds and deploys makes it easy to accidentally deploy an untested rebuild, or to lose the audit trail of what was promoted and when. Keeping GitOps deployment as its own concern, driven by its own tool, keeps that boundary honest.

See Kargo for how a validated change actually moves between environments.