GitOps

GitOps, coined by Weaveworks in 2017, is an operational framework that applies the principles of Git-based collaboration to infrastructure and application delivery. The core idea is simple but powerful: the desired state of your entire system -- Kubernetes manifests, Helm charts, Kustomize overlays, Terraform configurations -- lives in a Git repository. An automated agent running inside the cluster (Argo CD, Flux) watches the repository and continuously reconciles the actual cluster state to match what is declared in Git. If the repository says 'Deployment X should have 3 replicas running image v2.1.0,' the agent ensures exactly that.

The key distinction between GitOps and traditional CI/CD is the push vs. pull model. In traditional CI/CD, the pipeline pushes changes to the cluster: after building an image, the CI system runs 'kubectl apply' or 'helm upgrade' against the cluster. This requires the CI system to have cluster credentials and creates a one-way flow -- the pipeline knows what it deployed, but nothing continuously ensures the cluster matches the intent. In GitOps, the agent inside the cluster pulls changes from Git. The CI pipeline's only job is to build and push the container image, then update the image tag in the Git repository. The GitOps agent detects the change and reconciles.

This pull-based model provides several critical advantages. First, security: cluster credentials never leave the cluster. The GitOps agent has read access to Git and write access to the cluster, but CI pipelines and developers never directly access production clusters. Second, auditability: every change to the cluster is a Git commit with an author, timestamp, reviewer (from the PR), and diff. Third, self-healing: if someone manually modifies the cluster (kubectl edit, console change), the agent detects the drift and reverts it, continuously enforcing the desired state. Fourth, rollback: reverting a bad deployment is 'git revert' -- the agent reconciles the cluster to the previous state.

GitOps implementations typically separate the application repository (source code, Dockerfiles) from the configuration repository (Kubernetes manifests, Helm values). The CI pipeline builds the application, pushes the image, and opens a PR to the config repository updating the image tag. After PR approval and merge, the GitOps agent deploys the change. This separation enables independent release cycles for application code and infrastructure configuration, and prevents CI pipeline permissions from escalating to cluster access.

Imagine a shared spreadsheet (Git) that defines every item in your warehouse (cluster): 'Shelf A: 10 units of Product X, Shelf B: 5 units of Product Y.' A warehouse manager (GitOps agent) checks the spreadsheet every minute and ensures the physical warehouse matches exactly. If someone moves items without updating the spreadsheet (manual kubectl change), the manager puts them back (drift correction). To add a new product, you update the spreadsheet (Git commit), and the manager stocks it automatically. To undo a mistake, you revert the spreadsheet edit (git revert), and the manager adjusts the warehouse. Every change is tracked with who made it and when (git log). No one needs keys to the warehouse (cluster credentials) -- they just need access to update the spreadsheet.