We love maturity models, but you must take great care when deciding whether they are the appropriate tool for the job. In DevOps, the volume of practices and the number and variety of contexts make maturity models a poor fit. It’s far better to review all available options within your context when deciding how to deliver software better.
GitOps is different. Strong agreement exists on the handful of principles and practices. The State of GitOps research also confirms that the practices are mutually supportive, so you must use them in concert, not alone.
Based on the research, we can create a maturity model inspired by the great work done in the past but updated based on statistical analysis of what organizations are doing and what works.
This new GitOps maturity model provides an evidence-backed path from early foundations to operating at scale.
The current version of the GitOps maturity model is: v2025.1.
The statistical model
Based on the research, we build a statistical model of relationships between GitOps practices and many outcomes. The model highlighted where there was a link between a practice and an outcome and also the strength of the relationship.
The statistical analysis revealed several key insights that inform this maturity model:
- Practice Dependencies: Certain GitOps practices show strong statistical correlation with others, indicating natural adoption paths for practices
- Outcome Correlation: The data demonstrates clear relationships between specific practices and both DevOps and GitOps-specific outcomes
- Cumulative Effect: Organizations practicing multiple GitOps practices simultaneously show exponentially better results than those cherry-picking individual practices
We can combine these elements into a simplified maturity model diagram by showing the practices driving the 3 DevOps and 5 GitOps outcomes.
In the model, solid outlines indicate practices based on statistical research. This GitOps maturity model is advantageous as it’s technology and vendor-neutral. While many teams use GitOps for Kubernetes, the research found that a solid percentage of organizations use it for other technology stacks. The maturity model doesn’t recommend specific tools because you’ll select different options based on what you need to deploy and to where.
The research data shows that organizations adopting these practices achieve measurably better outcomes across deployment frequency, lead times, change failure rates, and mean time to recovery compared to those attempting to skip stages or implement practices in isolation.
The maturity model will be updated based on feedback, with future research being used to validate any suggestions.
Pre-adoption
Before adopting GitOps, organizations use familiar workflows with code commits triggering CI/CD events and manually-driven infrastructure updates, either using ClickOps or manually triggering infrastructure scripts.
This leads to some predictable challenges:
- Deployment inconsistency: Without a single source of truth, environment configurations drift apart. Production has a different configuration to staging, so there’s no guarantee the application you tested will work when exposed to the differences.
- Manual intervention: When deployments fail, or environments drift, teams resort to manual fixes, creating snowflake infrastructure that becomes increasingly difficult to troubleshoot and impossible to recreate.
- Limited audit trail: Traditional ops depends on a system to capture change and this lacks comprehensive logging of who changed what, when, and why. The level of bureaucracy required adds administrative burden without delivering a robust system for audit and compliance.
- Reactive resolution: Teams typically discover configuration drift or deployment issues after problems manifest in production, leading to longer recovery times and increased customer impact.
- Tool sprawl: Different teams often adopt different tools and practices, creating a heterogeneous landscape that’s difficult to secure, monitor, and maintain.
- Security vulnerabilities: Traditional infrastructure management requires elevated access control to infrastructure and management portals, creating larger attack surfaces and compliance challenges.
The State of GitOps research found those in the pre-adoption phase had the lowest software delivery performance and were least likely to attain the benefits of GitOps.
1. Foundations
At the foundations stage, drift may be detected and teams notified, but correction often remains manual. The primary benefit is visibility, as teams can see what changed, when, and who made the change. This foundation creates the trust and transparency necessary for the more advanced practices that follow.
Practices:
- Declarative desired state: Describes your target end state, making it easier to understand, change, and review.
- Human readable format: Makes it easier to manage configuration and take advantage of version control tooling.
- Version control: Provides the infrastructure for access control, storage, review, history, and audit trails.
Culture:
- Generative culture / psychological safety: Ideas are welcome and it’s safe to experiment.
- Shift infrastructure left: Infrastructure configuration is treated with the same care as application code.
- Collaborative configuration management: Multiple team members collaborate to manage configuration.
2. Depth
At the depth stage, drift is detected and corrected automatically. This solidifies the practice of making all changes through version control, even in an emergency.
Practices:
- Responsive code review: Keeps changes flowing smoothly, reduces merge conflicts, and encourages changes to be made the GitOps way.
- Automatic pull: Improves security by having the agent call back to version control instead of exposing endpoints to a central system.
- Continuous reconciliation: Keeps your system in the target state and encourages all changes to go through version control.
Culture:
- GitOps for all changes: Changes are made the GitOps way, even in emergencies.
- Shift from reactive to proactive: Focus shifts to earlier interventions for reliability.
- Operational confidence: The team trusts the GitOps reconciliation loop.
3. Platform
At the platform stage, the organization is looking to apply GitOps practices universally and will seek a high level of standardization. Templates may be offered to accelerate onboarding, though they may lose consistency as teams evolve them independently.
Practices:
- Recreatable applications: Proves you’ve captured all the infrastructure and application configuration required to spin up a new environment on demand.
Culture:
- High degree of standardization: Many teams converge on good practices and apply them to all GitOps workflows.
- Security baked in: GitOps includes security practices as part of the workflow, not a separate activity.
- GRC needs met: Governance, risk, and compliance needs are considered and incorporated.
4. Scale
The scale stage is where organizations apply GitOps broadly across production workloads. This involves alignment across multiple providers, clouds, and locations so software teams are decoupled from hosting choices. Where templates are offered, mechanisms are in place to manage how template improvements are rolled out to all teams that use them.
Practices:
- Template management: Lets template improvements be easily rolled out to all teams.
- Cross-platform configuration management: Decouples teams from your infrastructure choices by providing a unified configuration.
Culture:
- Non linear application cost: The organization can scale the breadth of adoption with sub-linear cost increases.
- Continuous improvement culture: GitOps workflows and templates are regularly refreshed to improve them.
- Center of excellence: The organization provides training and support, encouraging broad alignment on GitOps use.
Summary of maturity levels
All the cultural capabilities and practices are listed below, along with their maturity levels.
| Level | Category | Facet |
|---|---|---|
| 1. Foundations | Practice | Declarative desired state |
| 1. Foundations | Practice | Human readable format |
| 1. Foundations | Practice | Version control |
| 1. Foundations | Culture | Generative culture / psychological safety |
| 1. Foundations | Culture | Shift infrastructure left |
| 1. Foundations | Culture | Collaborative config management |
| 2. Depth | Practice | Responsive code review |
| 2. Depth | Practice | Automatic pull |
| 2. Depth | Practice | Continuous reconciliation |
| 2. Depth | Culture | GitOps for all changes |
| 2. Depth | Culture | Shift from reactive to proactive |
| 2. Depth | Culture | Operational confidence |
| 3. Platform | Practice | Recreatable applications |
| 3. Platform | Culture | High degree of standardization |
| 3. Platform | Culture | Security baked in |
| 3. Platform | Culture | GRC needs met |
| 4. Scale | Practice | Template management |
| 4. Scale | Practice | Cross-platform configuration management |
| 4. Scale | Culture | Non-linear cost of applications |
| 4. Scale | Culture | Continuous improvement culture |
| 4. Scale | Culture | Center of excellence |
Adoption tips
Culture first: Starting with culture and education is how you achieve the best outcomes. DevOps research has shown that generative culture and psychological safety are the pre-requisites for high-performing teams and GitOps is no different. When culture is prioritized over tooling, organizations report better adoption outcomes.
Start small, think big: The data for breadth of GitOps adoption highlighted how organizations begin with a single application that’s representative of a large set of use cases, allowing them to polish the skills and learn tools before rolling GitOps out to many similar applications. This slow-slow-fast approach maximizes learning opportunities, reduces risk, and provides a springboard for broadening adoption quickly.
Measure continuously: The outcomes described in the research also provide useful measures of your GitOps progress. You can self-assess against the DevOps and GitOps outcomes and use what you learn to improve your adoption. Data-driven improvement accelerates maturity progression and helps you recognize and avoid bias.
Ready to improve your GitOps?
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.
