0 / 24

Model 34 of 74 · Technology & Data

DevOps / CI-CD Maturity Assessment

Assess DevOps culture, automation, and delivery pipeline maturity.

Pillars & areas

Culture

Align teams & mindset

  1. 01Culture & Collaboration
  2. 02Continuous Integration

Automate

Automate the pipeline

  1. 03Continuous Delivery & Deployment
  2. 04Infrastructure as Code & Automation

Assure

Observe & protect

  1. 05Monitoring, Observability & Feedback
  2. 06Security & Compliance in the Pipeline

Levels

  1. 1Manual & SiloedIsolated & hand-cranked
  2. 2Automated & IntegratedShared & predictable
  3. 3Continuous & Self-HealingOn-demand & autonomous

01 Culture & Collaboration

Do development and operations teams share ownership, communicate openly, and work toward common delivery goals?

0/4 answered

CC-1How do development and operations teams work together on delivery?

Think about whether developers and operations staff sit in separate groups with separate goals, or whether they share accountability for getting software into production.

CC-2How does your organisation handle blame when production incidents occur?

Consider what happens in the first hour after a major outage — are people focused on restoring service, or on identifying who caused the problem?

CC-3How visible is the state of the delivery pipeline to everyone involved?

Think about whether a new team member could walk in today and immediately see what is being built, what is in progress, and what is blocked.

CC-4How does your organisation share knowledge about systems and tooling across teams?

Consider whether critical knowledge about how things are built, deployed, and run is documented and accessible, or locked in a few people's heads.

02 Continuous Integration

Does the team integrate code frequently, validate it automatically, and keep the main branch in a releasable state?

0/4 answered

CI-1How frequently do developers integrate their work into the shared main branch?

Think about the typical lifespan of a feature branch — hours, days, or weeks.

CI-2What happens automatically when code is pushed to the repository?

Consider the full set of checks that run without anyone having to trigger them manually.

CI-3How does the team respond when the main branch build breaks?

Think about how long a broken build typically stays broken, and whether anyone drops what they are doing to fix it.

CI-4How does the team manage test quality and coverage?

Consider whether tests are trusted, maintained, and actually catch real bugs, or whether they are written once and gradually ignored.

03 Continuous Delivery & Deployment

Can the team release any version of the software to any environment on demand with confidence?

0/4 answered

CD-1How are software releases deployed to production?

Think about the steps between 'code is merged' and 'users see the change' — how many of those steps require a human to do something manually.

CD-2How quickly can your team roll back a bad production deployment?

Think about the last time a deployment caused problems — how long did it take to restore the previous working version.

CD-3How does the team manage environment parity across development, staging, and production?

Consider whether the staging environment behaves the same as production, or whether 'works in staging, breaks in prod' is a common experience.

CD-4How frequently does the team release to production?

Think about the gap between finishing a feature and users being able to use it.

04 Infrastructure as Code & Automation

Is infrastructure defined, versioned, and managed through code rather than manual configuration?

0/4 answered

IA-1How is infrastructure provisioned and configured?

Think about what happens when the team needs a new server, database, or network configuration — is it clicking through a console or running code.

IA-2How does the team manage configuration differences between environments?

Consider whether environment-specific values (URLs, credentials, feature toggles) are hard-coded, scattered in documents, or managed systematically.

IA-3How does the team handle database schema changes and data migrations?

Think about whether database changes are a source of deployment fear or a routine, automated step.

IA-4How much of the team's routine operational work is automated?

Consider tasks like log rotation, certificate renewal, scaling, backups, and user provisioning — how many still require someone to remember to do them.

05 Monitoring, Observability & Feedback

Can the team understand what is happening in production, detect problems early, and use data to drive improvement?

0/4 answered

MO-1How does the team know when something is wrong in production?

Think about how the team typically finds out about production problems — from users, from alerts, or from dashboards they are actively watching.

MO-2How does the team investigate production issues?

Consider what tools and data are available when someone is debugging a problem at 2 AM — can they trace a request across services, or are they reading raw log files on individual servers.

MO-3How does the team use production data to improve the software?

Think about whether production metrics and user behaviour data actually influence what the team builds next, or whether they are only looked at during incidents.

MO-4How does the team measure and track deployment success?

Consider whether the team knows, with data, whether a deployment made things better or worse — not just whether it 'worked'.

06 Security & Compliance in the Pipeline

Is security built into the delivery pipeline rather than bolted on at the end?

0/4 answered

SC-1At what point does security testing happen in the development lifecycle?

Think about whether security checks happen before code reaches production, or only during periodic assessments or after an incident.

SC-2How does the team manage secrets and sensitive credentials?

Consider where database passwords, API keys, and certificates are stored — in the code, in environment variables, or in a dedicated secrets management system.

SC-3How does the team manage third-party dependencies and supply chain risk?

Think about whether the team knows what open-source libraries are in production, whether they are up to date, and what would happen if a critical vulnerability were announced in one of them.

SC-4How does the team handle audit trails and change traceability for compliance purposes?

Consider whether you could prove to an auditor exactly who changed what, when, why, and whether it was approved — for every change in the last 12 months.

Self-assessment report

DevOps / CI-CD

Answer the questions above and your report builds here: an overall score, a score and target for each area, and the three changes that matter most.

About this model

About the DevOps / CI-CD maturity model

DevOps is not a toolset or a team name — it is a set of practices and a culture that brings development and operations together to deliver software faster, more reliably, and with shorter feedback loops. This model treats DevOps maturity as a progression from manual, siloed work toward fully automated, continuously improving delivery systems where quality, security, and reliability are built in rather than inspected after the fact.

The model deliberately avoids measuring tool adoption. A team using the most sophisticated toolchain in the industry can still be at the lowest maturity level if their culture, processes, and feedback loops are broken. Conversely, a team with simple tools but strong collaboration, fast feedback, and disciplined automation can operate at a very high level of maturity.

This assessment covers six areas that together represent the essential capabilities of a mature DevOps organisation: the cultural foundation that makes collaboration possible, the integration and delivery pipelines that automate the path to production, the infrastructure practices that make environments reproducible, the observability that turns production into a source of learning, and the security practices that keep the pipeline trustworthy.

The model uses three maturity levels that reflect how most organisations actually evolve: from manual and siloed operations, through automated and integrated pipelines, to continuously improving, self-healing delivery systems. Each level builds on the previous one — you cannot sustainably reach Level 3 without having established the foundations of Level 2.

The assessment contains 24 questions across 6 areas, with 4 questions per area. Every answer describes concrete, observable behaviours rather than aspirational statements, so teams can honestly assess where they stand today and identify specific actions to move forward.

Who this assessment is for

This model is designed for:

  • Engineering managers and tech leads who want to benchmark their team's delivery practices and identify the highest-impact improvements
  • Platform and infrastructure engineers responsible for building and maintaining CI/CD pipelines, deployment tooling, and developer experience
  • CTOs and VPs of Engineering who need a structured view of delivery capability across multiple teams to guide investment decisions
  • DevOps and SRE teams looking to assess their own maturity and communicate gaps to leadership with specific evidence
  • Organisations adopting DevOps practices who need a roadmap that goes beyond tool selection to address culture, process, and measurement

The three maturity levels

Level 1 — Manual & Siloed

Development and operations are separate disciplines with separate goals and incentives. Developers write code and hand it off; operations deploy it and deal with the consequences. Builds are triggered manually, deployments are nerve-wracking events that require coordination meetings and weekend windows, and production problems are discovered when users complain. Knowledge is concentrated in a few individuals, infrastructure is configured by hand, and the team has limited visibility into what is running in production.

Organisations at this level typically release infrequently (monthly or quarterly), experience high change-failure rates, and spend significant time on manual, repetitive operational work.

Level 2 — Automated & Integrated

The key shift at this level is automation and shared responsibility. CI/CD pipelines handle building, testing, and deploying code automatically. Developers and operations staff participate in the same planning and review processes. Infrastructure is defined in code. Environments are reproducible. Alerts fire on key metrics before users notice problems. Security scans run as part of the pipeline rather than as a separate annual exercise.

Organisations at this level release weekly or more frequently, can roll back a bad deployment in under 30 minutes, and have enough observability to diagnose most production issues without logging into individual servers.

Level 3 — Continuous & Self-Healing

At this level, the delivery pipeline is not just automated — it is continuously optimised based on production telemetry. Deployments happen on demand, often multiple times per day, and are so routine that they require no special coordination. Systems detect anomalies and can recover automatically. Security is embedded at every stage of the pipeline. Operational toil is systematically measured and reduced. The organisation treats production as a source of learning, using real-world data to drive development priorities, validate hypotheses, and improve reliability.

Organisations at this level have very short lead times (hours from commit to production), low change-failure rates, and fast recovery times measured in minutes rather than hours.

The 6 areas assessed

1. Culture & Collaboration

The foundation of DevOps maturity. This area assesses whether development and operations teams share ownership of delivery outcomes, communicate openly, respond to failure with learning rather than blame, and make their work visible to the entire organisation. Without cultural alignment, even the best tooling produces fragile results.

2. Continuous Integration

The practice of frequently merging code into a shared main branch, validating it with automated tests, and keeping the codebase in a releasable state at all times. This area measures integration frequency, the breadth and reliability of automated checks, the team's response discipline when builds break, and the quality and trustworthiness of the test suite.

3. Continuous Delivery & Deployment

The ability to release any version of the software to any environment on demand, with confidence. This area covers the degree of deployment automation, the speed and reliability of rollback, consistency across environments, and the frequency of production releases. The distinction between delivery (the ability to release at any time) and deployment (actually releasing automatically) is reflected in the maturity progression.

4. Infrastructure as Code & Automation

The practice of defining, provisioning, and managing infrastructure through version-controlled code rather than manual configuration. This area assesses how infrastructure is provisioned, how configuration is managed across environments, how database changes are handled, and how systematically the team eliminates manual operational toil.

5. Monitoring, Observability & Feedback

The capability to understand what is happening in production, detect problems before users do, investigate issues efficiently, and use production data to drive improvement. This area distinguishes between basic monitoring (knowing when something is broken) and full observability (understanding why it is broken and how to prevent it), and assesses whether production telemetry actually influences what the team builds.

6. Security & Compliance in the Pipeline

The integration of security practices directly into the delivery pipeline rather than treating them as a separate, periodic activity. This area covers the timing and breadth of security testing, the management of secrets and credentials, the handling of third-party dependency risk, and the ability to demonstrate full change traceability for audit and compliance purposes.

How this model relates to other frameworks

  • DORA (DevOps Research and Assessment) — Software delivery performance metrics: deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time
  • Google SRE (Site Reliability Engineering) — Practices around service-level objectives, error budgets, toil reduction, and incident management
  • The Three Ways (Gene Kim) — Flow, feedback, and continuous learning as foundational DevOps principles
  • Accelerate (Forsgren, Humble, Kim) — Research-backed model linking technical practices to organisational performance
  • CALMS Framework — Culture, Automation, Lean, Measurement, and Sharing as pillars of DevOps adoption

Frequently asked questions

What is the DevOps / CI-CD maturity model?

Assess DevOps culture, automation, and delivery pipeline maturity. It is an original, simplified model with three maturity levels (Manual & Siloed, Automated & Integrated and Continuous & Self-Healing), assessed through 24 questions across 6 areas: Culture & Collaboration, Continuous Integration, Continuous Delivery & Deployment, Infrastructure as Code & Automation, Monitoring, Observability & Feedback and Security & Compliance in the Pipeline.

How long does the DevOps / CI-CD assessment take?

Most people finish in 10–14 minutes. Each of the 24 questions has three concrete answer options. Your progress is saved in the page URL, so you can bookmark it and come back later.

How is the score calculated?

Each answer scores 1 (Manual & Siloed), 2 (Automated & Integrated) or 3 (Continuous & Self-Healing). An area's score is the average of its answered questions, and the overall score is the average of the area scores, so every area counts equally. Scores run from 1.0 to 3.0.

Is my data stored or shared?

No. Your answers are never sent to a server. They are stored only in the page URL, which you control. Copy the link to share results with colleagues, or export a PDF or CSV report.

How should I use the results?

Start with "Where to focus" in your report. It lists the questions with the biggest gap to the target you set for each area, and shows what the next level looks like in practice. For a fuller picture, ask several people from different teams to complete the assessment and compare their links. Differences in perception are often as revealing as the scores themselves.