GitOps

WHAT IT IS. GitOps applies version-control discipline to operations. The desired state of applications and infrastructure is declared declaratively in Git; software agents pull that state and continuously reconcile the live world against it; every change — human or pipeline — is a merge request with review, history, and a one-command rollback. The OpenGitOps project (CNCF) codifies it as four principles: declarative, pulled automatically, continuously reconciled, and agent-promoted… with the declaration itself living in Git. The principles, not any particular tool, are the content of this page. WHY IT EXISTS. Push-based deployment scripts answer "what did we run?" — GitOps answers "what SHOULD be running, and is it?" That difference is operational: drift between declared and actual state is detected automatically instead of discovered during an incident; recovery from a bad state is a git revert rather than archaeology through change logs; and authorization collapses to write-access on the repo, which auditors and humans can actually reason about. WHEN TO USE IT. When the estate has enough moving parts that "what changed?" becomes hard to answer — multiple services, environments, or clusters — and especially for Kubernetes, where the API is natively declarative and reconciliation is the platform's own pattern. A single static server does not need it; a ten-service estate with humans kubectl-ing into production absolutely does. WHO OWNS IT. Service teams own their declaration repos — their manifests, their promotion branches. The platform group owns the reconciliation policy: which controllers run where, enforce versus notify mode per environment, and the promotion flow between them. Nobody owns "the deploy button," because there is no deploy button — that is the point. WHAT GOOD LOOKS LIKE. The full production estate is reconstructable from Git plus data stores. Controllers run in enforce mode for production (notify-only is a staging posture, or a permanent half-adoption), reconciliation is fast enough that a reverted manifest is reality within minutes, drift alerts fire when reality and declaration diverge — including the human who changed something by hand, which is then either codified or reverted deliberately. Promotion from dev to prod is a PR moving a commit pointer, reviewable by anyone. HOW TO IMPLEMENT. Pick one real service — not a toy. Declare it (or import its existing Kubernetes state), put it under a controller (Argo CD and Flux are the CNCF-hosted references) in notify mode, and live with the drift reports for a week — they are free incident reports. Fix the recurring drifts by codifying them, then flip the service to enforce. Expand service by service; treat any system someone can mutate outside Git as the next thing to bring in. HOW TO ASSESS YOURSELF. The production readiness assessment scores deployment automation and rollback — the two capabilities GitOps exists to make real: /assess. The maturity ladder below stages from push scripts (L1) to full-estate enforced reconciliation with drift SLAs (L5). Related: /devops is the broader change culture, /cloudops owns what is declared, /platform-engineering builds the paved road on top.