GitOps combines the best ideas from DevOps and infrastructure as code (IaC). By storing definitions of infrastructure and applications in version control, teams can use familiar tools to make, review, rollback, and audit those changes. Just like DevOps, there are cultural and technical elements to GitOps. Teams agree to flow all changes through declarative state files and decide on the collaboration around changes. Once a team makes a change, high levels of automation ensure they are applied.
How GitOps works: The reconciliation loop
At the core of GitOps is a reconciliation loop that:
- Observes the system’s current state
- Compares it to the desired state
- Makes adjustments to align them
The loop runs continuously, keeping your system in sync with the configuration in version control.
The 4 GitOps principles
The Open GitOps project provides 4 technology-agnostic principles that define a widely accepted definition of GitOps.
1. Declarative
A system managed by GitOps must have its desired state expressed declaratively.
You must express your system’s desired state declaratively. Instead of writing step-by-step instructions, you describe what you want the result to look like. This approach separates what you want from how to get there, eliminating problems caused by assumptions about starting conditions.
3. Pulled Automatically
Software agents automatically pull the desired state declarations from the source.
Software agents automatically pull configuration from version control. This means your configuration doesn’t need to know where it’s going or how many destinations it serves.
2. Versioned and Immutable
Desired state is stored in a way that enforces immutability, versioning, and retains a complete version history.
Store your desired state in version control to ensure it’s versioned, immutable, and maintains a complete history. This lets you to diagnose issues and roll back changes when needed.
4. Continuously Reconciled
Software agents continuously observe the actual system state and attempt to apply the desired state.
Agents continuously monitor the actual system state and work to align it with the target state defined in version control.
The 6 practices that make GitOps work
GitOps research defines 6 specific practices that drive successful GitOps outcomes. These practices work together, so you need all of them to get the full benefits, though you don’t have to implement them all at once.
- Declarative desired state
- Human readable format
- Responsive code review
- Version control
- Automatic pull
- Continuous reconciliation
1. Declarative desired state
Declarative configuration gives you a clear target to aim for. Unlike imperative approaches that require you to think through every step, declarative configuration describes your target end state. This makes it easier to understand, change, and review.
Benefits:
- Clear documentation of your target state
- Simpler changes and reviews
- Readable change history
- Automation handles the complexity
2. Human readable format
If humans can’t easily read your configuration files, you lose most of the value that version control provides. Instead of simple diffs, you’d have to load different versions into specialized tools for comparison.
Benefits:
- Changes follow familiar developer workflows
- Reviews happen within standard code review tools
- Version control provides natural change history
- Configuration serves as documentation
3. Responsive code review
Quick reviews keep changes flowing smoothly. Slow GitOps reviews create delays that encourage teams to work in larger batches, which is where most software delivery problems start. When reviews are slow, teams often bypass GitOps entirely, losing the benefits of review and change tracking.
Benefits:
- Smaller, less risky changes
- Version control becomes the primary way to change systems
- Better throughput with fewer bottlenecks
4. Version control
While many consider version control fundamental to GitOps, the other practices make version control truly effective. Version control provides the infrastructure for access control, storage, review, history, and audit trails.
Benefits:
- Single source of truth for system state
- Familiar tools and processes
- Complete change history with rollback capability
5. Automatic pull
When you use agents to pull configuration from version control improves security, you don’t need to expose endpoints for remote commands. Instead of a central system pushing changes out, agents collect configurations on their own schedules.
Benefits:
- Better security with no exposed endpoints
- No need to coordinate multiple destinations
- Simpler architecture
6. Continuous reconciliation
Continuous reconciliation keeps your system in the target state and encourages all changes to go through version control. Manual changes get detected and corrected quickly. While you can implement this with human intervention, automatic reconciliation works better and faster.
Benefits:
- Confidence that systems stay in the intended state
- Strong incentive to make all changes through version control
- Faster detection and correction of drift
Getting Started
Most teams shouldn’t try to implement all 6 practices at once. A gradual approach works better. Establish one practice, build your skills, and then add the next one. This gives you time to work through challenges, like creating declarative configurations for existing applications.
Ready to Assess Your GitOps Maturity?
Use our GitOps self-assessment to see where you stand and get specific recommendations for improvement. You can also dive deeper into the research behind these practices in our State of GitOps report.
Help us continuously improve
Please let us know if you have any feedback about this page.
