GitOps has become one of the most overloaded terms in the DevOps space. You mention it in a meeting and everyone nods — but ask them to define it and you’ll get five different answers.
Let me offer a cleaner mental model.
GitOps is a set of principles, not a tool
The OpenGitOps project defines four core principles:
- Declarative — The desired state of the system is expressed declaratively
- Versioned and immutable — The desired state is stored in a way that preserves history
- Pulled automatically — Approved changes are applied automatically
- Continuously reconciled — Software agents continuously ensure actual state matches desired state
Notice that none of these say “use ArgoCD” or “use Flux.”
The real shift is cultural
The hardest part of GitOps adoption isn’t deploying ArgoCD. It’s convincing your team that:
- Git is the source of truth — no more
kubectl applyfrom laptops - PRs are deployment mechanisms — every change goes through review
- Drift is an incident — your cluster should match your repo, always
This requires discipline and buy-in. Tools can enforce it, but the culture has to come first.
When GitOps doesn’t fit
GitOps is brilliant for application workloads. It’s awkward for:
- Stateful systems — databases don’t reconcile well
- Secret bootstrapping — you can’t put secrets in Git (use External Secrets Operator)
- One-off operations — runbooks and debug sessions live outside the GitOps flow
My take
Adopt GitOps for its principles. Pick a tool (ArgoCD, Flux, whatever) that fits your team’s preferences. But don’t mistake installing ArgoCD for “doing GitOps” — the mindset shift is where the real value lives.
What’s your experience with GitOps adoption? I’d love to hear in the comments or on Discord.
