The State of Deployment & Release Engineering 2026
How frequent shipping, progressive delivery, and release automation rest on a fast, reliable pipeline, and what rollback rates reveal about who actually has one.
Executive summary
Deployment cadence is the most visible output of an engineering organization, and in 2026 the center of gravity has shifted decisively toward frequent, small, automated releases. The share of teams deploying daily or better keeps climbing, driven by the realization that small batches are safer than large ones and that the path to production should be a button, not a project. The teams still releasing monthly are increasingly the outliers rather than the norm.
The mechanism behind frequent shipping is progressive delivery: canaries, blue-green, and feature flags that let a change reach production gradually and roll back automatically if signals degrade. This decouples deploy from release and turns a scary all-or-nothing event into a series of cheap, reversible steps. Rollback rate becomes a health signal rather than a mark of shame, because a team that can roll back instantly ships more boldly than one for which every reversal is a crisis.
None of this works without a fast, reliable build-and-verify pipeline underneath. Every canary promotion, every flag flip, every rollback runs a pipeline, and a slow or flaky one re-introduces the very risk progressive delivery was meant to remove. The release machinery is only as trustworthy as the CI it sits on, which is why the teams with the best cadence are almost always the teams with the best pipelines.
This report maps the cadence curve against DORA's published performance bands, traces the automation frontier from build through promotion, and shows where reliable CI is the load-bearing wall of modern release engineering. It also quantifies how rollback rate falls as release strategy matures, and why that fall is a story about confidence rather than caution.
The encouraging finding is that the path from cautious to confident is mostly infrastructure rather than reorganization. A team does not need to restructure to ship daily; it needs progressive-delivery tooling and a pipeline fast and reliable enough that running it on every promotion is cheap. That makes frequent shipping an achievable target for teams that feel stuck at weekly or monthly today.
Share of teams by how often they deploy to production. · Source: Synthesized from DORA + Latchkey analysis
Share of teams using each gradual-release technique in production. · Source: Latchkey analysis (modeled)
Email me the report
The full report is right here on this page, free. Want the link in your inbox to read later or share, plus new Latchkey reports as they drop? Drop your email and we will send it over.
Sent! Check your inbox for the report link.
No spam. Unsubscribe anytime.
Daily-or-better is the new center of gravity
The deployment-cadence distribution has shifted left toward frequency, with a large and growing share of teams shipping daily or on demand. DORA's published bands put elite performers at on-demand (multiple per day), and the rest of the field is steadily migrating toward that end of the curve rather than away from it. Frequent shipping is no longer an exotic capability reserved for the largest platform teams, it is becoming the expected default.
The driver is risk math. A small change is easier to verify, deploy, and reverse than a large batched one, so shipping often with small diffs is not reckless, it is the safer choice. The teams clustered at the monthly end are not de-risking by waiting; they are accumulating risk, because each rare release carries weeks of accumulated change that all lands at once, and the blast radius of a problem grows with the size of the batch.
The chart below shows the cadence distribution across the field. The mass is moving toward the on-demand and daily bands, and the long tail of monthly and slower releases increasingly belongs to teams constrained by a slow or manual path to production rather than by a deliberate choice to batch. For most of those teams the constraint is mechanical, which means it is fixable.
Progressive delivery decouples deploy from release
Feature flags, canaries, and blue-green deploys let teams put code in production without exposing it to everyone at once, turning release into a dial rather than a switch. The deploy, getting the code onto servers, becomes a low-stakes mechanical act, while the release, turning the feature on for users, becomes a separate, gradual, reversible decision. Separating those two has done more to make frequent shipping safe than any other single practice.
Feature flags lead adoption because they are the cheapest entry point, requiring no infrastructure beyond a conditional in the code. Canaries and blue-green come next, and the full payoff arrives when automated rollback closes the loop so that a degraded signal reverses itself without a human in the path. The chart below shows where each technique sits on the adoption curve, and the gap between flag adoption and automated rollback marks the work most teams still have ahead of them.
The reason the loop has to close automatically is timing. A human-in-the-loop rollback is only as fast as the human notices, and degradation during a canary can move faster than an on-call engineer can react. Automated rollback tied to real signals is what lets a team promote aggressively, because the cost of being wrong is a few minutes of partial exposure that the system reverses on its own rather than an incident.
- Feature flags lead adoption because they are the cheapest entry point, needing no new infrastructure.
- Canary and blue-green strategies follow, decoupling the mechanical deploy from the user-facing release.
- Automated rollback is the lagging technique, and it is the one that finally takes the human out of the reaction path.
- Every one of these techniques runs a pipeline on each promotion, so their value is capped by pipeline reliability.
Rollback rate is a confidence signal, not a scarlet letter
Teams using progressive delivery show the lowest effective rollback impact, not because they make fewer mistakes but because their rollbacks are small, automatic, and routine rather than rare and catastrophic. A reversal that affects two percent of traffic for ninety seconds barely registers as an event, while a big-bang rollback that pulls a month of batched change is an all-hands incident. The same word, rollback, describes two completely different experiences.
This is why rollback rate read in isolation is misleading. A healthy rollback rate is a sign the safety net works and the team is willing to use it, and the teams with the highest release confidence are precisely the ones that have made reversing a change cheap. Punishing teams for rolling back optimizes for the wrong thing: it teaches them to avoid the safety net rather than to ship safely.
The chart below shows modeled rollback rates falling steadily as release strategy matures, from big-bang monthly down to progressive delivery. The falling number reflects smaller batches and faster, automated reversal, not heroics. A team that wants a lower rollback impact does not get there by being more cautious, it gets there by making each change smaller and each reversal cheaper.
Modeled share of deployments that require a rollback, by approach. · Source: Latchkey analysis (modeled)
The release path is mostly automated until the last gate
On mature teams the great majority of the path from build to canary promotion runs without human intervention, with manual approval reserved for a final high-stakes gate. The build and test, the deploy, the canary, and much of the verification are machine work; the human appears once, at the moment of broad promotion, where judgment still earns its place. The chart below shows roughly four fifths of the path automated and a single manual gate remaining.
The remaining manual steps are where release engineering effort now concentrates. Shrinking that last gate safely is not about deleting the human, it is about giving the human enough automated signal that the decision becomes routine, or about replacing the manual judgment with automated checks trustworthy enough to gate on. Both moves depend entirely on a verify-and-promote pipeline the team actually believes.
That trust is the crux. A team will not automate away its final approval gate if the pipeline that would replace the human is slow or flaky, because the gate exists precisely to catch what the pipeline might miss. Making the pipeline fast and reliable is therefore the prerequisite for automating the last manual step, which is why release-engineering maturity and CI reliability advance together rather than separately.
Estimated split of release-path steps that are fully automated on a mature team. · Source: Latchkey analysis (modeled)
Reliable CI is the load-bearing wall of release engineering
Every promotion, flag flip, and rollback runs a pipeline, so a slow or flaky pipeline silently re-imports the risk progressive delivery was built to remove. A canary that cannot be promoted because the verification pipeline is stuck in a queue is a canary that sits half-released, and a rollback that waits on a flaky build is a rollback that arrives after the damage. The release machinery inherits every weakness of the CI underneath it.
Because 76 percent of professional developers depend on CI/CD in their daily flow, this pipeline is not an edge case, it is the spine of how software reaches production. When it is fast and reliable, progressive delivery feels effortless and teams promote freely. When it is slow, the same techniques feel heavy, and teams quietly batch more and ship less to avoid paying the pipeline tax repeatedly.
Managed, self-healing runners that scale instantly and recover from transient failures keep the release loop fast and trustworthy, so frequent shipping stays cheap as well as safe. Latchkey targets roughly 70 percent below GitHub-hosted compute, which matters because the pipeline runs on every promotion and rollback, so its per-run cost is multiplied across a cadence that, by design, is supposed to be high.
Pipeline wait time is where release confidence quietly leaks
Frequent shipping only feels good when the feedback loop is short. When CI wait time is long, every promotion carries a delay, and that delay is one of the top daily frictions developers report, sitting alongside unclear requirements and flaky tests near the top of the list. A release strategy that is fast in theory becomes slow in practice if every step waits on a sluggish pipeline.
The friction compounds because release work is iterative. A canary that needs adjustment, a flag that needs flipping, a fix that needs shipping, each is another trip through the pipeline, so a slow loop taxes the release path repeatedly rather than once. Teams feel this as release fatigue, and they respond, rationally, by shipping less often, which is the opposite of what their progressive-delivery investment was supposed to buy.
This is why cutting CI wait time is a release-engineering investment, not just a developer-experience one. A pipeline that returns quickly keeps the promote-verify-rollback loop tight, so the team stays in the fast cadence its tooling enables. Removing queue time, cold starts, and transient flake from the critical path is what lets a team's actual cadence match the cadence its release strategy was designed for.
- CI and build wait time ranks among the top recurring daily frictions developers report, near unclear requirements and flaky tests.
- Release work is iterative, so a slow pipeline taxes the promote-verify-rollback loop repeatedly rather than once.
- Teams respond to a slow loop by batching more and shipping less, which undoes the benefit of progressive-delivery tooling.
Most release-pipeline failures are mechanical, not real
A meaningful share of failed promotion and verification runs are not caused by anything wrong with the change. They are transient: a registry timeout pulling a dependency, a flaky integration test, a cold cache, an out-of-memory kill on an undersized runner. These pass on a clean retry, which is the tell that the change was fine and the environment hiccuped.
In a release context these mechanical failures are unusually costly, because they strike at the worst moment. A transient failure during a canary promotion stalls a release that was going fine, and a flaky failure on a rollback pipeline delays a fix exactly when speed matters most. Treating these as real failures sends a team chasing phantom bugs in a change that was always correct.
Self-healing runners attack this directly by retrying transient failures on a fresh environment before a human sees a red check. The promotion proceeds, the rollback ships, and the on-call engineer is not paged to investigate a problem that did not exist. Removing the mechanical failure class from the release path is what keeps automated promotion and rollback trustworthy enough to leave running without a human watching every step.
Recommendations
Make production deploy a button, not a project
Automate the path from merge to production so that shipping a single small change is cheap and routine. The teams stuck at weekly or monthly cadence are usually constrained by a slow or manual release path, not by a deliberate choice to batch, and automating the path is what unlocks the small-batch discipline that makes frequent shipping safe.
Adopt progressive delivery, then close the loop with automated rollback
Start with feature flags because they are the cheapest entry point, then add canaries and blue-green. The full payoff arrives only when automated rollback takes the human out of the reaction path, because degradation can move faster than an on-call engineer can respond. Automated reversal is what lets a team promote aggressively.
Read rollback rate as confidence, not failure
Track rollback rate, but interpret it as a measure of whether the safety net works rather than a mark of shame. Punishing rollbacks teaches teams to avoid the safety net instead of shipping safely. A healthy rollback rate on a progressive-delivery team reflects small, cheap, routine reversals, which is exactly what you want.
Shrink the last manual gate by earning trust in the pipeline
The final approval gate exists because the pipeline is not yet trusted to catch everything. Invest in making verification fast and reliable so the gate can shrink to a routine confirmation or be replaced by automated checks. Release-engineering maturity advances in lockstep with CI reliability, not ahead of it.
Put the release pipeline on fast, self-healing managed runners
The pipeline runs on every promotion, flag flip, and rollback, so its speed and reliability set the ceiling on cadence. Managed, self-healing runners that scale instantly and recover transient failures keep the loop tight and cheap, at roughly 70 percent below GitHub-hosted rates, so frequent shipping stays affordable as cadence rises.
Outlook
Expect the cadence curve to keep shifting toward on-demand and daily through 2026 and into 2027, with the monthly and slower bands increasingly populated by teams constrained by a slow path to production rather than by deliberate choice. The techniques in this report compound: a team that ships small and often gets faster feedback, which makes the next small change safer, which makes shipping often easier still. The teams that stay at low cadence feel the opposite compounding as their batches grow.
The architectural direction is convergence. Progressive delivery, automated rollback, and a fast self-healing pipeline are becoming a single expected baseline rather than three separate investments, because each one depends on the others to pay off. Automated rollback needs a trustworthy pipeline; a trustworthy pipeline makes the last manual gate shrinkable; a shrinking gate makes progressive delivery effortless. The pieces reinforce one another, which is what makes the pattern durable.
For most teams the practical takeaway is that confident, frequent shipping is mostly an infrastructure problem, not an org-chart one. It needs an automated release path, progressive-delivery tooling, and a runner layer fast and reliable enough that running the pipeline on every promotion is cheap. The organizations that internalize that will spend the next two years shipping daily with low rollback impact while their peers keep treating each release as an event.
Methodology
This report synthesizes DORA's publicly published deployment-frequency findings and performance bands with Latchkey's own analysis of release-engineering practices and CI/CD runner economics. Figures and bands attributed to DORA reflect its published findings and should be verified against the current report. The 76 percent CI adoption figure reflects the Stack Overflow Developer Survey. Figures labeled "modeled" are illustrative estimates derived from typical release pipelines and progressive-delivery patterns, not a primary survey. Figures labeled "modeled" are illustrative estimates derived from public pricing and typical pipeline shapes, not a primary survey; figures attributed to a named source reflect that source. Pricing reflects published rates at time of writing and should be verified against current provider pricing.