GitOps applies software-development discipline to operations: the desired state of the entire system is described declaratively in a Git repository, which becomes the single source of truth. Deployments are no longer manual kubectl commands but the natural result of a Git change, giving full auditability and easy rollback.
Working principle
A controller running in the cluster (Argo CD, Flux) continuously compares the live state with the declared state in Git and reconciles any difference — pulling changes automatically. Combined with progressive delivery, a new version is released to a small slice of traffic (canary), its health metrics are watched, and the rollout either advances automatically or rolls back — all driven from Git.
| Aspect | Push (script deploys) | GitOps (pull/reconcile) |
|---|---|---|
| Source of truth | Pipeline state | Git repository |
| Drift | Possible, hidden | Detected & corrected |
| Rollback | Re-run pipeline | Git revert |
| Audit | Pipeline logs | Full Git history |
Why it mattersBecause Git is the source of truth, recovery is trivial: revert the commit and the cluster heals itself back to the known-good state.
Applications
- Declarative, auditable Kubernetes deployments at scale
- Safe canary / blue-green releases with automated rollback
- Multi-cluster and disaster-recovery consistency
References & further reading
- Weaveworks, “GitOps: Operations by Pull Request,” 2017.
- OpenGitOps / CNCF, “GitOps Principles v1.0,” 2022.
- Argo CD & Flux project documentation, 2023–2025.