You’ve seen DevOps, DevSecOps, and maybe even NoOps. But GitOps is the next evolution worth understanding — and if you’re already using Git-based workflows with CI/CD pipelines and infrastructure-as-code, there’s a good chance you’re already doing parts of it.
The term GitOps was coined by Alexis Richardson at Weaveworks, initially in the context of running Kubernetes-based infrastructure. But the concept is broader than Kubernetes: it’s a philosophical and operational approach to software development and deployment applicable to any organization running its own code on its own infrastructure.
This article draws on a piece originally published at thenextweb.com and expands on the core concepts for a DevOps engineering audience.
What Is GitOps?
GitOps is the culmination of several trends in modern software engineering — version control, infrastructure-as-code, and CI/CD automation — taken to their logical conclusion. Together, these practices create a workflow where:
- The entire system state is declared in a Git repository.
- Automated tooling continuously reconciles the live environment to match what is declared in Git.
- Every change to the system goes through a pull request, creating a complete audit trail.
In short: Git is the source of truth, and the system automatically converges to match it.
The Three Pillars of GitOps
1. Single Source of Truth
The first and most fundamental GitOps principle is that Git — or any version control system you use — is the single source of truth for application code, infrastructure definitions, and configuration. This means:
- The complete state of your system can be understood by reading the repository.
- There are no hidden settings changed manually on a server somewhere.
- If something is wrong, the problem exists in the repo — and it’s in the commit history.
This principle eliminates the classic problem of configuration drift, where the live environment silently diverges from what anyone intended.
2. Everything as Code
GitOps extends “infrastructure as code” to cover the full system description:
- Application code — your services and their dependencies.
- Configuration as code — environment configs stored in YAML or similar formats in the repo, not in a database or configuration management UI.
- Infrastructure as code — compute resources, networking, and cluster definitions expressed as code (e.g., Terraform, Kubernetes manifests, Docker Compose files).
When all three are present in the repository, the repo becomes a complete, human-readable description of the system.
3. CI/CD Automation
This is where the model becomes powerful. Automated CI/CD pipelines watch the repository and act on changes:
- A merged pull request triggers a pipeline.
- The pipeline tests, builds, and deploys the system to match the declared state in Git.
- If the live system drifts from the declared state (due to hardware failure, manual intervention, or any other cause), reconciliation tooling detects the divergence and corrects it.
Nick Young, Principal Engineer at Atlassian, described this elegantly as “declaring the desired state of things and then waiting for the system to bring the world into line with the desired state.”
Why Adopt GitOps?
GitOps delivers benefits at both the philosophical and practical level.
Auditability and Reversibility
Every change to the system passes through a pull request. This gives you:
- A full audit trail of who changed what and why.
- Instant rollback capability — revert the commit, and the automation restores the previous state.
- Peer review as a standard gate before any change reaches production.
Consistency and Reduced Context-Switching
Instead of bouncing between cloud console UIs, configuration management dashboards, and code editors, developers work entirely in one tool: Git. Managing application code and managing infrastructure use the same workflow.
Faster Recovery
When an incident occurs, the entire system state is readable in the repository. Debugging and remediation start from a known, documented position rather than archaeological investigation of manual changes.
New Challenges GitOps Introduces
GitOps is not without its complications. Understanding them before adoption saves significant pain.
Shifting Quality Gates Further Left
In a GitOps workflow, merging to the main branch can directly trigger a production deployment. This means:
- Pre-merge validation becomes critical. A typo in a YAML Ansible template or a Kubernetes manifest can break or expose a production system.
- Automated linting, schema validation, and policy checks (e.g., Open Policy Agent) on pull requests are essential safeguards, not optional extras.
- Developers must build habits around validating infrastructure code as rigorously as application code.
Secrets Management
Storing everything in Git raises an immediate question: what about secrets? Credentials, API keys, and certificates must never be stored in plaintext in a repository. GitOps workflows require a dedicated secrets management strategy — such as integrating with a secrets manager and referencing secrets by reference rather than value in the repository.
Drift Detection and Reconciliation
The live system can change in ways Git does not know about — hardware failures, emergency manual interventions, or misbehaving operators. A complete GitOps implementation requires tooling that continuously monitors the live system and alerts on — or automatically corrects — divergence from the declared state in the repository.
Progressive Delivery
Because changes can reach production quickly, GitOps workflows typically rely on canary deployments or feature flags to limit blast radius. A canary deployment routes only a small percentage of traffic to a new version, allowing teams to validate behavior before full rollout. This is not unique to GitOps, but it becomes more important when the pipeline between commit and production is short.
GitOps and Kubernetes
GitOps originated in the Kubernetes ecosystem, and Kubernetes is well-suited to it: Kubernetes is itself declarative by design, accepting YAML manifests that describe desired state and reconciling the cluster to match. Tools like Flux and Argo CD implement GitOps reconciliation loops specifically for Kubernetes clusters, continuously syncing cluster state to a Git repository.
That said, the underlying principles — version-controlled declarative configuration, automated deployment, drift detection — can be applied outside Kubernetes using other tooling.
Are You Already Doing GitOps?
Full GitOps is an aspiration for many organizations, but most modern teams are already practicing parts of it. Ask yourself:
- Do you store infrastructure definitions or configurations in Git?
- Do you use an automated CI/CD pipeline triggered by commits or pull requests?
- Do you require pull request reviews before merging changes that affect production?
If you answered yes to any of these, you’re already on the GitOps spectrum. The journey to fuller GitOps adoption is largely about closing the gaps: ensuring all configuration is in Git, automating more of the deployment loop, and adding drift detection.
Key Takeaways
- GitOps makes Git the single source of truth for code, configuration, and infrastructure.
- The system automatically converges to match what is declared in the repository.
- Every change goes through a pull request, providing auditability and rollback capability.
- Pre-merge validation is critical — automated linting and policy checks guard against bad merges reaching production.
- Secrets must be managed separately — never stored as plaintext in the repository.
- Drift detection tooling is required to handle unexpected live-system changes.
- Full GitOps adoption is incremental — start by codifying more of your configuration and infrastructure, and automate progressively.