This article summarises Puppet’s 2018 State of DevOps Report, as reported by bdaily.co.uk. All quotes and stage definitions are attributed to Puppet’s published research.
DevOps Maturity in 2018: Still a Work in Progress
By 2018, DevOps had moved well beyond buzzword status. Most enterprises had launched some form of DevOps initiative, and many had evolved into round-the-clock software delivery organisations. Yet results varied enormously from one company to the next. Some teams were shipping multiple times per day with high confidence; others were still struggling with siloed workflows and manual deployments.
To understand why outcomes differed so dramatically, Puppet analysed survey responses from thousands of technology professionals and published its findings in the 2018 State of DevOps Report. A central output of that analysis was a structured, six-stage maturity model — numbered Stage 0 through Stage 5 — designed to give organisations a clear map of the DevOps journey and concrete practices to focus on at each point.
Nigel Kersten, VP of Ecosystem Engineering at Puppet, summarised the challenge: “While DevOps practices have become far more well known across our industry, organisations continue to struggle to scale pockets of DevOps success more broadly across multiple teams and departments. This year’s report explores the foundational practices that need to be in place in order to scale DevOps success, and proves that success can only scale when teams are enabled to work across functional boundaries.”
The Six-Stage DevOps Maturity Model
The model is sequential but not rigid — organisations may find themselves stronger in some areas than others. The value of the framework is that it identifies which foundational capabilities must exist before later-stage practices can take hold reliably.
Stage 0: Build the Foundation
Everything begins here. Development and operations teams are starting to recognise the importance of collaboration and shared responsibility. The primary activity at this stage is rapidly putting in place the mechanisms that enable sharing: shared metrics, shared knowledge bases, common communication channels, and early cross-functional processes.
This stage is deceptively important. Skipping or rushing through it tends to produce DevOps initiatives that look good on paper but collapse under the weight of cultural friction later on. The health of a mature DevOps organisation is directly proportional to how solid this foundation is.
Key focus areas: cross-team communication, shared visibility into metrics, early process documentation, and establishing psychological safety for experimentation.
Stage 1: Normalise the Technology Stack
At Stage 1, development teams begin adopting more disciplined engineering practices. The most significant marker is the adoption of version control — a prerequisite for everything that comes later, including continuous integration and continuous delivery. Teams may also begin moving toward agile development methods, either through a coordinated organisational initiative or organically, team by team.
On the operations side, the focus is on beginning to rationalise the technology landscape: identifying redundant systems and starting to reduce the sprawl of operating systems, runtimes, and deployment mechanisms that accumulated over years of ungoverned growth.
Key focus areas: universal version control adoption, introduction of CI tooling, initial tech stack rationalisation, and early agile practices.
Stage 2: Standardise and Reduce Variability
Stage 2 extends the rationalisation effort that began in Stage 1. Both development and operations teams work in parallel to drive down variance across the entire system. This typically means converging on a single operating system or OS family, and standardising the core components of the application stack: databases, message queues, key-value stores, identity providers, and similar infrastructure primitives.
The business impact is concrete. When every team builds on the same approved patterns, new applications and services can be deployed faster because the underlying infrastructure is already well understood. Errors that stem from environment inconsistency — the classic “works on my machine” category — are significantly reduced. Critically, as shared patterns mature and improve, the quality improvement is multiplied across every service that uses them.
Key focus areas: OS standardisation, approved component libraries, elimination of one-off configurations, and shared deployment patterns.
Stage 3: Expand DevOps Practices
With a stable, well-understood technical foundation in place, organisations can now address higher-order pain points. At Stage 3, teams systematically reuse proven deployment patterns rather than building one-off pipelines for each project. Equally important: infrastructure changes are tested before being applied to production environments — a shift that significantly improves reliability and reduces the blast radius of configuration errors.
These practices build trust — both within teams and between development and operations. And trust, according to Puppet’s research, is the prerequisite for the deeper cultural changes that enable DevOps to scale. Without demonstrated reliability, there is no appetite for the autonomy that characterises high-performing DevOps organisations.
Key focus areas: reusable pipeline templates, infrastructure testing (e.g., using tools like Test Kitchen, Serverspec, or InSpec), pre-production validation gates, and cross-team pattern libraries.
Stage 4: Automate Infrastructure Delivery
Stage 4 is where many organisations set their sights when they first launch a DevOps programme — but Puppet’s model makes clear that reaching it requires the groundwork laid in earlier stages. At this point, the automation of system configuration and provisioning becomes the norm rather than the exception. Infrastructure-as-code practices are mature enough that teams can spin up consistent, compliant environments reliably and repeatedly.
Self-service provisioning begins to emerge here, enabling multiple departments to provision resources without opening tickets and waiting for manual intervention. The operational efficiency gains are significant, as is the reduction in toil for infrastructure teams.
Key focus areas: infrastructure-as-code at scale (e.g., Puppet, Ansible, Terraform), automated provisioning pipelines, configuration drift detection, and early self-service workflows.
Stage 5: Provide Self-Service Capabilities
Stage 5 represents the cumulative payoff of everything built in the preceding stages. At this level of maturity, resources are available on demand through self-service interfaces. Incident response is largely automated — alert, diagnose, and remediate workflows operate without requiring manual handoffs at every step.
Crucially, Puppet’s report emphasises that automation at this stage is purposeful. High-performing teams don’t automate for its own sake; they automate to give the entire organisation — not just IT — the ability to operate with greater speed, efficiency, and precision. The engineering investment pays dividends across every business unit that depends on software and infrastructure.
Key focus areas: internal developer platforms, self-service provisioning portals, automated incident remediation, and organisation-wide reliability engineering practices.
Why the Staged Model Matters
One of the most practical insights from Puppet’s 2018 report is that DevOps failure is rarely about the wrong tools — it is almost always about attempting later-stage practices before the earlier-stage foundations are solid. Organisations that jump straight to infrastructure automation without standardising their stack, or that roll out self-service before establishing trust between teams, tend to create fragile systems that amplify existing dysfunction rather than resolving it.
The model is also a useful diagnostic. If a team is struggling to scale DevOps beyond a few pioneering squads, mapping current practices against the five stages can quickly surface which foundational capabilities are missing — whether that is inconsistent version control adoption, untested infrastructure changes, or an absence of shared deployment patterns.
Takeaways for DevOps Teams
- Start with culture and visibility before investing heavily in tooling. Stage 0 is not optional.
- Version control is non-negotiable at Stage 1 and is the gateway to every subsequent automation practice.
- Standardisation reduces complexity in ways that compound over time — every team benefits when shared patterns improve.
- Test infrastructure changes before production as rigorously as you test application code.
- Automate with purpose — the goal is organisational efficiency, not automation for its own sake.
- Self-service is an outcome of mature automation, not a starting point.
For organisations assessing where they stand, Puppet’s staged framework provides a structured way to identify gaps, prioritise investments, and set realistic expectations about the time and effort required to reach the higher stages of DevOps maturity.