DevOps Statistics 2026: 12 Numbers on Delivery, CI/CD, Testing, and AI
A planning meeting can go sideways when every dashboard seems to tell a different DevOps story. AI looks ubiquitous in one survey; another finds it rare inside CI/CD; a cloud-native sample reports widespread Kubernetes production use. The mistake is not that any one number is necessarily wrong. It is assuming they share a population or measure the same activity.These DevOps statistics collect the latest available 2024–2025 evidence for a 2026 reader. They are not a 2026 census and they should not be combined into a single industry average. Use them to frame questions about adoption, delivery, and quality—then measure those questions in your own delivery system.
Key DevOps statistics for 2026
90% of respondents reported using AI in their work
in Google Cloud and DORA’s 2025 survey of nearly 5,000 technology professionals worldwide. This is survey research about AI use at work, not AI use specifically in CI/CD. (Google Cloud/DORA)
89% of respondents reported cloud-native adoption
in CNCF’s 2024 Annual Survey of 750 cloud-native community respondents who shared their experiences in fall 2024. This is a CNCF survey result, not an all-enterprise adoption rate. (CNCF)
80% of respondents reported running Kubernetes in production
in that same 750-respondent CNCF 2024 survey. (CNCF)
60% of respondents reported using CI/CD for most or all applications
in CNCF’s 2024 survey of cloud-native community respondents fielded in fall 2024. (CNCF research announcement)
77% of respondents reported adopting GitOps principles for deployment
in the same CNCF 2024 survey population. (CNCF research announcement)
83% of developer respondents reported involvement in DevOps-related activities
in the CD Foundation’s 2024 State of CI/CD report. It describes that report’s respondents, not every developer worldwide. (CD Foundation)
CircleCI analyzed more than 14 million data points from real software-delivery pipelines
for its 2025 State of Software Delivery report. This is vendor operational data from CircleCI’s ecosystem, not a representative sample of all pipelines. (CircleCI)
73% of respondents said they did not use AI in CI/CD workflows
in JetBrains’ 2025 survey of 805 participants worldwide. This is a vendor-commissioned survey result about a specific workflow. (JetBrains)
32% of organizations used two CI/CD tools and 9% used at least three
in the same 805-participant JetBrains 2025 survey. These are tool-count figures, not measures of delivery quality. (JetBrains)
92% of respondents in the IT industry reported container usage, compared with 30% across industries
, in Docker’s 2025 State of App Development survey of more than 4,500 developers, engineers, and technology leaders. The two percentages use different populations. (Docker)
64% of respondents said non-local environments were their primary development setup
in Docker’s 2025 survey of more than 4,500 technical respondents. “Primary” does not mean respondents used no local environment at all. (Docker)
45.65% of State of Testing respondents said they had not integrated AI tools into testing; 40.58% reported AI use for test-case creation and 34.7% for realistic test-data generation
in PractiTest’s 2025 State of Testing report announcement, published January 15, 2025. These are survey-reported testing uses, not evidence of improved test effectiveness. (PractiTest announcement)
Get the Mobile Testing Playbook Used by 800+ QA Teams
Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.
How to read DevOps statistics without mixing denominators
The figures above fall into three evidence types: survey responses, observed platform data, and measurement definitions. Each answers a useful question, but none can answer all three.A survey response tells you what a defined group says it uses or experiences. It can reveal adoption patterns, such as how many respondents report container use or CI/CD across most applications. It cannot, by itself, prove that the practice caused a delivery outcome.Operational data comes from activity a platform observed. CircleCI’s dataset is valuable because it is drawn from real pipeline events rather than recollection. But the platform’s customers, workloads, configurations, and usage patterns still define its scope.A measurement framework does something else again: it gives you consistent language for examining your own system. DORA metrics are most useful in that role. They are not industry targets that every product or organization should hit.If you are turning these DevOps statistics into a business case, keep the source, population, fielding period, and evidence type next to the number. That small discipline prevents a cloud-native community result from becoming a claim about every organization.
Use DORA metrics to inspect delivery performance
DORA’s current framework has five software-delivery performance metrics. It separates them into throughput and instability, which helps you avoid treating speed as the whole story. (DORA’s metrics guide)
Track throughput alongside recovery
Change lead time is the time from committing a change to version control to deploying it to production. It shows how long a completed change takes to reach users.Deployment frequency is the number of deployments in a period, or the time between deployments. You can choose the representation that makes sense for your release cadence, but use it consistently.Failed deployment recovery time is the time required to recover from a failed deployment that needs immediate intervention. A frequent release schedule is less reassuring if recovery is slow when a release goes wrong.
Track instability alongside throughput
Change fail rate is the ratio of deployments that require immediate intervention after deployment. It asks whether releases are creating production problems that need action.Deployment rework rate is the ratio of unplanned deployments caused by a production incident. It distinguishes planned delivery work from reactive fixes.For your own scorecard, these measures work better as a balanced set than as a maturity label. A single deployment-frequency figure tells you little about whether changes arrive safely, recover quickly, or generate rework.DORA’s 2025 research adds an important AI context: it describes AI as an amplifier of an organization’s existing strengths and weaknesses. Broad AI use should therefore prompt you to inspect delivery conditions, not assume the tooling improved them. (DORA 2025 report)
What CI/CD adoption says—and what it cannot say
The CNCF and CD Foundation findings indicate that DevOps-related practices are widely reported within their respective communities. JetBrains’ tool-count result adds a more practical complication: your CI/CD environment may be a collection of tools rather than a single standardized system.That distinction matters when you decide what to measure. Two organizations can both say they use CI/CD for most applications while having very different approval flows, test gates, deployment paths, and incident-response responsibilities. Adoption is a reach measure; it is not a reliability score.Tool multiplicity is not automatically a problem, either. You may run multiple CI/CD tools because you support different application types, inherited systems, or regulatory boundaries. It becomes an operational question when ownership, reporting, or release criteria cannot travel across those boundaries.Start with the path a change takes in your environment. Identify where code is built, where tests run, which results block promotion, who can override a gate, and where production evidence is recorded. If you need a practical companion to that mapping exercise, this guide to CI/CD tools for DevOps and developers can help you compare the roles tools play without treating the category as one product.CircleCI’s large operational dataset is a reminder to prefer your own observed pipeline events when you need performance answers. Survey benchmarks can frame a conversation; timestamps, failed-deployment records, and recovery events can tell you what happened in your delivery system.
Testing and quality statistics expose a missing link
The retained testing data describes where respondents report using AI in test work. It does not show whether those uses improve coverage, reduce flaky reruns, shorten feedback cycles, or detect more production defects.That is a meaningful gap in the public DevOps statistics available here. There is no verified common-denominator measure connecting CI/CD adoption or pipeline reliability to test effectiveness, mobile defect detection, or real-device coverage. No published Quash telemetry or completed Quash experiment is available to supply that missing mobile-specific evidence.Treat that absence as a measurement prompt for your organization. Pair the delivery metrics above with quality measures that reflect the risks you actually ship: escaped defects, test pass reliability, time from failed run to actionable diagnosis, and coverage of the user flows that matter to releases.For example, a pipeline can be fast while its test signal is weak. A green build only supports confidence when you know what the suite exercised, whether failures are trustworthy, and whether critical environments were represented. Continuous testing in DevOps is the operational practice of running those checks throughout the delivery lifecycle rather than leaving validation until the end.The PractiTest results make a narrower point: AI use in testing is uneven and concentrated in identifiable tasks such as test-case creation and realistic test-data generation. Use that as a prompt to evaluate a specific workflow, not as evidence that AI has solved quality measurement.
Cloud-native infrastructure changes the delivery context
The CNCF survey findings put cloud-native adoption, Kubernetes production use, CI/CD use, and GitOps adoption in the same cloud-native community context. That combination is useful for understanding why deployment workflows increasingly involve declarative infrastructure and distributed runtime environments.It is not a universal architecture prescription. Your organization may have a monolith, a regulated legacy system, a mobile backend, or a mix of services that calls for different release controls. The relevant question is whether your deployment process gives you a clear and recoverable route from a change to a production outcome.Docker’s survey results add another context: non-local development environments are a primary setup for many of its respondents, while container usage differs sharply between IT-industry respondents and the cross-industry group. Your development environment can affect reproducibility, onboarding, and how closely a local check resembles pipeline execution, but a survey percentage cannot establish those outcomes for your system.When you assess infrastructure, document the environments in which code is built, tested, and released. Then look for mismatches: tests that pass locally but fail in CI, configuration that differs between staging and production, or device and browser conditions absent from automated checks. That gives you an investigation plan rather than an adoption statistic with nowhere to go.
Broad AI use is not AI adoption in CI/CD
The DORA, JetBrains, and PractiTest findings appear to conflict only if you remove their labels. DORA asks about AI use in work; JetBrains asks about AI in CI/CD workflows; PractiTest reports on AI integration in testing.These are different activities and different respondent groups. The more precise conclusion is that broad AI use can coexist with uneven adoption in specialized delivery and quality workflows.For your roadmap, replace the broad question—“Are we using AI?”—with a workflow question. Are you using it to generate tests, summarize failures, review changes, modify pipeline configuration, or assist incident recovery? Then define the evidence you will use to judge that workflow: review time, false positives, recovery time, coverage, or another metric tied to the job.This approach also limits a common reporting error. A high general-use percentage does not establish that AI is running in your CI/CD process, and use in a process does not establish a performance improvement. The outcome has to be measured where the workflow runs.
What these figures do not establish
These figures do not provide a global DevOps average. Their populations range from cloud-native community respondents to developers, testing respondents, and users of a delivery platform. Their collection periods also differ.They do not establish causation. Reported use of Kubernetes, GitOps, containers, or AI may be associated with many organizational conditions that a single survey result does not capture.They also do not support a single market-size claim. Public DevOps market estimates often differ in category definition, geography, currency, base year, and forecast horizon. Combining them would create a trend line with more apparent precision than comparable evidence.The practical implication is simple: use external statistics for context, then make your operational decisions from measurements that match your application, architecture, release process, and risk tolerance.
Methodology and source notes
This report includes figures from first-party survey announcements, foundation-published research, a vendor operational-data report, and DORA’s measurement guide. The latest observations available for this 2026 compilation were collected or published in 2024 and 2025.Each statistic retains its source population rather than being converted into an industry-wide denominator. Survey figures are presented as reported behavior, while CircleCI’s figure is labeled as platform operational data. DORA’s five metrics are definitions for measuring software delivery performance, not externally verified performance bands.Market-size estimates are excluded because no comparable primary-source definition was available across the estimates considered. Testing claims are limited to the reported AI-in-testing uses because the available public evidence does not establish a shared CI/CD-to-test-effectiveness benchmark.
Conclusion
The useful takeaway from DevOps statistics is not that a particular tool or practice has crossed an adoption threshold. It is that delivery now spans infrastructure, pipelines, testing, and AI workflows that need separate evidence.Use adoption figures to understand what respondents report doing. Use DORA’s throughput and instability measures to inspect delivery. Then add quality measures that reflect the failures your users can experience. Your decision is not whether your stack looks mature on a survey; it is whether you can show that changes reach production quickly, recover safely, and preserve the quality you intend to ship.
Continue reading
More articles from the Quash editorial desk.
