What is GitOps?
Git as the single source of truth for what runs in production: the desired state lives in the repository, a controller applies it to the real system.
GitOps is the practice of using a Git repository as the single source of truth for how a production system should be configured, typically a Kubernetes cluster or the cloud infrastructure around it. The desired state, which versions run, how many replicas, which configuration, lives in files inside the repository. A controller (Argo CD, Flux and similar) continuously watches the repository and compares it against the system's real state: if they diverge, it reconciles them automatically, instead of waiting for someone to run a deploy command. The term was coined in a 2017 Weaveworks post, and the underlying idea is simple: treat production as a pure function of the repository, not as the result of commands run by hand. This reconciliation sets GitOps apart from a plain "deploy from a pipeline": if someone manually changes an object in the cluster, the controller notices and reverts the system to the declared state, turning configuration drift into a visible event instead of a silent risk found during an incident.
The difference from classic deployment
In traditional deployment, a CI/CD pipeline actively pushes changes toward the target system: the "push" model. In GitOps the controller inside the cluster pulls the state from the repository: the "pull" model, and the difference is not just technical. No one needs direct credentials to change production: changing the repository, after review, is enough. Every change to the system's state automatically has a Git history, an author, a reason, and rolling back means reverting a commit, not reconstructing from memory what used to run.
How it ties to IaC and CI/CD
GitOps is the natural evolution of Infrastructure as Code applied to the continuous release cycle: IaC describes infrastructure as code, CI/CD automates testing and build, GitOps closes the loop by deciding that the only thing authorized to change production is an approved commit in the right repository. For a data or platform team it means a full audit trail of every environment change and a way to recover from a configuration incident with the same discipline used to recover from a bug in application code.
Related terms
- Infrastructure as Code (IaC) · Describing servers, networks and cloud services in versioned code files instead of configuring them by hand, so infrastructure is created and recreated reproducibly.
- CI/CD · Continuous Integration and Continuous Delivery: every software change is tested and shipped to production automatically and frequently.
- Platform engineering · The discipline building self-service internal platforms for teams: golden paths, shared tooling and infrastructure treated as a product.
- AI-Assisted Testing / Agentic QA · AI agents that generate tests, self-heal them, and run whole regression suites: they triage failures and suggest fixes.
- DevSecOps · The DevOps extension that builds security into the CI/CD pipeline as a shared responsibility, not a separate final gate.
A term that hits close to home? Let's talk.
CONTACT ME