GitOps
Keeping deployed state in Git and letting a controller make the live system match what the reviewed repository declares.
What it is
GitOps makes a Git repository the approved record of deployed state. An agent such as Argo CD or Flux continuously compares that desired state with a running Kubernetes cluster and reconciles differences. Changing production therefore starts with a commit and pull request, not a command from an operator's laptop. Weaveworks coined the name in 2017 while running Kubernetes this way in production.
Reach for it when you want deployments to inherit Git's review, history, and rollback mechanics. It works especially well for declarative systems: a merged manifest says what should exist, and the controller keeps working until the cluster matches it.
Gotcha: putting everything in Git does not make everything safe to store there. Plaintext secrets remain plaintext throughout history, and a fast reconciler can faithfully restore a bad declaration after someone fixes production by hand. Encrypt secrets or reference an external store, protect the branch, and pause reconciliation during deliberate repair.
Ask AI for it
Set up GitOps for this Kubernetes application with Argo CD. Create an Application that tracks the production manifests in a protected main branch, set `syncPolicy.automated.prune` and `syncPolicy.automated.selfHeal` to true, and add the `CreateNamespace=true` sync option. Add health checks, a PreSync database-migration Job annotated with `argocd.argoproj.io/hook-delete-policy: HookSucceeded`, and Argo CD notifications for failed syncs. Store no plaintext secrets: use External Secrets Operator with AWS Secrets Manager. Document the pull request deployment path, the Argo CD rollback command, and the exact procedure for pausing auto-sync during incident repair.