ArgoCD / Flux (GitOps) · DevOps & CI/CD Deep Dive

The Idea

Pull, Don't Push

Desired state in Git — Kubernetes YAML / Helm values / Kustomize overlays committed to a repo.
Agent in the cluster — ArgoCD or Flux controller polls Git (or webhook), diffs against live state, applies changes.
Reconciliation loop — runs continuously, so manual changes (drift) get reverted or flagged.
Sync waves & hooks — order resources, run pre/post-sync jobs (DB migrations).
App of apps — one repo defines many apps; great for fleet management.

ArgoCD vs Flux

Aspect	ArgoCD	Flux
UX	Polished web UI showing live diff and topology	CLI-first; UI via third parties (Weave GitOps, Capacitor)
Model	`Application` CRD; per-app sync config	Modular: `GitRepository`, `Kustomization`, `HelmRelease` CRDs
Multi-cluster	Single ArgoCD managing many clusters; ApplicationSets	One Flux per cluster; pull is naturally distributed
Best for	Teams that want a dashboard and self-service	Teams that prefer composable controllers and cluster-local autonomy

Why GitOps

Audit trail is free — every change is a commit by a known author.
Rollback is git revert — no special pipeline path.
No CI credentials in the cluster. The cluster reads Git; CI doesn't need kubeconfig.
Drift detection — see (and optionally auto-correct) hand-edits.
Disaster recovery — bootstrap a fresh cluster by pointing the agent at the Git repo.

Tradeoffs

Secrets in Git need encryption — Sealed Secrets, SOPS, External Secrets Operator. Plain YAML won't do.
Image updates need a bridge — ArgoCD Image Updater or Flux's image automation; otherwise CI still has to commit a tag bump.
Two-system mental model. Engineers used to "CI deploys" can be confused that the cluster "pulls itself."
Repo-per-env vs mono-repo vs branch-per-env — there's no consensus pattern; pick early.

Continue