DevOps PeachWithout GitOps, a CI job usually ends with kubectl apply or helm upgrade run against the cluster. It works, but the pipeline needs cluster admin credentials, nobody can tell whether the cluster still matches what was deployed, and a manual kubectl edit at 2 a.m. is invisible.
GitOps turns this around. The desired state of every environment lives in a Git repository, and an agent inside the cluster compares it with the live state and fixes any difference.
The four OpenGitOps principles
| Principle | What it means in practice |
|---|---|
| Declarative | The system is described as data (YAML, Helm values, Kustomize), not as a script of steps. |
| Versioned and immutable | That description is stored in Git: every change is a commit with an author, a review and a history. |
| Pulled automatically | An agent in the cluster pulls the desired state; nobody pushes into the cluster from outside. |
| Continuously reconciled | The agent keeps comparing desired and live state and corrects drift. |
flowchart LR D["Developer"] -->|"pull request"| G["Git: shop-config"] CI["CI: build, test, push image"] -->|"bump image tag"| G A["Argo CD in the cluster"] -->|"pull every 3 min"| G A -->|"apply the difference"| K["Kubernetes"]
Push vs pull
| Push (classic CD) | Pull (GitOps) | |
|---|---|---|
| Who changes the cluster | The CI server | An agent in the cluster |
| Credentials | CI holds cluster credentials | Only the agent has cluster access; CI only writes to Git |
| Drift (manual change) | Unnoticed | Shown as OutOfSync, can be reverted automatically |
| Rollback | Re-run an old pipeline | git revert the commit |
| Audit | Pipeline logs | Git history and pull requests |
Two repositories, two jobs
Most teams split the work:
- Application repo – source code, Dockerfile, unit tests. CI builds and pushes an image such as
registry.example.com/shop-api:1.4.2. - Config (environment) repo – Kubernetes manifests, Helm values or Kustomize overlays for
dev,stagingandprod. A pull request that changes the image tag is the deployment.
This keeps a stream of code commits from triggering deployments by accident and gives the config repo its own reviewers.
Where Argo CD fits
Argo CD is a GitOps controller for Kubernetes and a CNCF graduated project. It watches Git repositories, renders manifests (plain YAML, Helm, Kustomize, Jsonnet), compares them with the cluster, shows the difference in a web UI and CLI, and syncs the cluster — manually or automatically. Flux is the other well-known GitOps tool; the ideas in this course apply to both.
What GitOps does not do
- It does not build images or run tests — that is still CI.
- It does not make secrets safe to commit — you need Sealed Secrets, External Secrets or similar (module 4).
- It does not replace monitoring: a perfectly synced app can still be broken.
Rule of thumb: if a change is not in Git, it should not exist in the cluster.