Most explanations of progressive delivery describe half of it. They cover canaries, rings, and percentage rollouts: the part where you widen a release slowly. Then they stop. The half they skip is the one that gives the idea its name. When RedMonk analyst James Governor coined “progressive delivery” in 2018, he defined it by two principles. The second one, handing release control to the person who owns the outcome, is what separates a delivery strategy from a deployment trick (RedMonk).
The reason this matters is blast radius. A big-bang release couples 100% of your users to a single moment in time. If the change is bad, everyone is already on it, and the only lever left is a redeploy. Progressive delivery breaks that coupling: expose the change to a sliver of traffic, watch, then widen. Make the widening a configuration change someone can reverse in one click.
Key Takeaways
- Progressive delivery exposes a release to users gradually, in controlled increments, instead of all at once. James Governor (RedMonk) coined the term in 2018 (RedMonk).
- It rests on two pillars: release progression (widen exposure at a safe pace) and progressive delegation (move release control to the outcome owner). Most write-ups cover only the first.
- Feature flags are the control plane for both. They decouple deploy from release and make a rollback a config push, not a redeploy.
- The payoff is smaller blast radius, faster detection, and faster recovery, which are the levers behind the metrics DORA tracks.
How to use this guide. This is the conceptual pillar: the full mental model, the technique rubric, and where flags fit. For the one-paragraph definition, see the progressive delivery glossary entry. For the rule-by-rule treatment of rollouts in a wider flag practice, see feature flag best practices. For the failure mode it replaces, see the big-bang release in feature flag anti-patterns.
1. What progressive delivery actually means
Progressive delivery is the practice of exposing a new release to production users in controlled increments: internal staff first, then a small canary, then a wider beta cohort, then everyone, with a checkpoint at each step. It isn’t a single tool. It’s an umbrella over a basket of techniques: canary releases, feature flags, dark launches, A/B testing, and blue-green deploys (RedMonk).
The term has a specific origin. James Governor of RedMonk coined it in mid-2018 after hearing Sam Guckenheimer describe Microsoft’s “progressive experimentation” model, and developed the idea with Adam Zimman, then at LaunchDarkly (SD Times). The framing has held up well enough that it now has a canonical book, Progressive Delivery: Build the Right Thing for the Right People at the Right Time (Governor, Harrison, Waterhouse, and Zimman, IT Revolution, 2025).
The mental model worth keeping is simple: deploy is not release. Deploying ships code to a server. Releasing decides who runs it. Progressive delivery is everything that happens between those two events. The more you can separate them, the less a deploy has to be an act of faith.
2. The two pillars: release progression and progressive delegation
Governor’s definition has two parts, and you need both to get the benefit. Release progression is adjusting how many people can see a change, at a pace the business can tolerate: beta users first, then a trusted group, then everyone. Progressive delegation is the under-told half. It means shifting release control out of the engineering and operations org and into the hands of the business or product owner accountable for the outcome (SD Times).
Why does the second pillar matter so much? Because a canary that only the platform team can advance is still a deployment strategy. It tells you whether the new version is healthy; it doesn’t tell you whether the feature is right for the audience. Delegation hands the dial to the person who can actually answer that: the PM who knows the beta cohort, the support lead watching ticket volume, the growth team running the experiment. The release stops being an ops event and becomes a product decision.
IT Revolution has since published a “Four A’s” framework that extends the model for teams formalising the practice (IT Revolution). But the two pillars are the load-bearing idea: widen exposure carefully, and let the right person own the widening.
3. Progressive delivery vs continuous delivery, canary, and blue-green
These terms get used interchangeably, and they shouldn’t be. Continuous delivery keeps a change in a deployable state at all times. It’s about the pipeline. Progressive delivery governs who sees the change after it’s deployed. It’s about exposure. Canary and blue-green are deployment-routing techniques. Feature flags are an application-layer technique. Progressive delivery is the strategy that orchestrates whichever of those you use.
A concrete way to keep them straight: continuous delivery gets the artifact to the door, progressive delivery decides how far it walks in. You can practise continuous delivery and still do big-bang releases, shipping to 100% the instant the pipeline goes green. Progressive delivery is the discipline you add on top to stop doing that.
The mechanic that ties it together is rollback economics. With a redeploy-based strategy, reverting means rebuilding and shipping again. With traffic routing, reverting means shifting weight back (Argo Rollouts). With a flag, reverting means flipping a value in config. That difference is the whole game: it cuts mean time to recovery, and because a regression first shows up against a small traffic slice, it cuts mean time to detection too.
4. The techniques that implement it
Progressive delivery is assembled from a handful of techniques, and the useful question isn’t “which is best” but “which risk am I managing.” Infrastructure and version risk point toward canary releases. Feature-level risk, like a new checkout flow that might be wrong, points toward flags. Validating performance before anyone sees a UI points toward dark launching. Here’s the map:
| Technique | Best when… | Blast radius at step 1 | Rollback |
|---|---|---|---|
| Dark launch | validating load or performance before users see anything | 0% (no UI exposed) | instant (turn the flag off) |
| Canary release | infrastructure or version risk; metric-gated promotion | small traffic slice | reroute traffic |
| Percentage rollout (flags) | feature-level risk, per-user consistency needed | 1–5% of users | flag config push |
| Ring-based | org-structured exposure (internal → beta → GA) | one ring at a time | flag or segment change |
| Blue-green | all-or-nothing cutover with a fast revert path | 0%, then 100% on cutover | swap back to the old environment |
Most real rollouts combine these. A team might dark-launch a new pricing service to validate it under production load, then put the user-facing change behind a percentage rollout once the backend is proven. The opposite of all this is the big-bang release: ship to everyone at once and hope. That’s exactly the pattern progressive delivery exists to retire.
The rings model maps cleanly onto these techniques. Each ring is a population (staff, canary, beta, broad, GA), and the technique you reach for decides how you route to that population: traffic weight for canary, a flag rule for a percentage rollout, a segment match for ring-based exposure.
5. How feature flags become the control plane
Feature flags are the mechanism that makes both pillars cheap, which is why they show up in nearly every progressive delivery story. They decouple deploy from release: ship the code dark, then turn it on when you choose. They make exposure a configuration value rather than a code change. A percentage rollout or a targeting rule is something you edit, not redeploy. And they make delegation safe, because flipping a flag in a dashboard is a far smaller blast radius than handing someone access to a deploy pipeline.
In code, the feature is just a branch behind a named decision:
// The rollout percentage and targeting live in config, not here.if (client.boolVariation('checkout-v3', user, false)) { renderCheckoutV3();} else { renderCheckoutV2();}The widening happens in the dashboard: 1%, then 5%, then 20%, then 100%. The code never changes between steps, and neither does the deploy. That’s the property that makes the rings chart above a configuration timeline rather than a deploy schedule.
This is the rung Featureflip occupies. Flags evaluate in-process in sub-millisecond time, configuration changes stream to every connected SDK, and a kill switch propagates fleet-wide without a deploy, so a rollback is a config push, not a release. Automated, metric-gated canary analysis is a complementary rung that teams layer on top of the flag control plane. That’s the kind that promotes or aborts a rollout based on live error budgets, which tools like Argo Rollouts and Flagger run at the infrastructure layer. Knowing which rung you’re standing on keeps the architecture honest. For the rule-by-rule version of rolling out well, see feature flag best practices.
6. Why it matters: the DORA case
Progressive delivery serves the metrics the DevOps research community has spent a decade measuring. It shrinks the impact of a change failure by shrinking the blast radius, it speeds recovery because a rollback is a flag flip, and it de-risks the higher deployment frequency that correlates with high-performing teams (DORA). The consistent finding across years of the research is counter-intuitive but well-established: the teams that deploy most often also fail least often. Speed and stability rise together, and the practices that allow that are the ones that make any single change reversible.
The 2025 State of DevOps report reshaped how it presents this. It moved away from the old elite/high/medium/low ladder toward seven team archetypes and per-metric buckets, and split its measures into throughput and instability groups. It also promoted “rework rate”, the share of deployments made to fix a user-visible problem, to a headline signal it had introduced in 2024 (DevOps.com; CD Foundation). The same report flags a sharp edge: AI-assisted teams are pushing throughput up but driving change failure rate up too, wherever their feedback loops can’t keep pace with the new velocity (DevOps.com).
That last point is the whole argument for progressive delivery in one line. A feedback loop is what it provides: a small, watched slice of traffic before the full release. If you’re shipping faster than ever, the question isn’t whether you can deploy quickly; it’s whether you can catch a bad change before it reaches everyone. Decoupling deploy from release, which is where this all started in the boundary between deploying and releasing, is what makes the loop possible.
7. How to start without a platform team
You don’t need Kubernetes, a service mesh, or an SRE rotation to start. The minimum viable progressive delivery loop is five steps: ship the change behind a flag (off), enable it for internal staff, expand to a small percentage of users, watch the dashboards you already have, then widen or roll back. That’s release progression with the tools most teams already own.
Start with one genuinely risky feature rather than mandating the practice everywhere at once. Run it through the rings (internal, canary, beta, GA), and resist the urge to skip steps when the early signals look good. The point of the loop is the steps you take when they don’t. Add the delegation pillar once the loop is trusted: let the PM or feature owner control the dial, so the release becomes their decision instead of a ticket they file with engineering.
One caution carries over from flag practice generally. A rollout flag is a temporary flag. Once you’ve stabilised at 100% for a release cycle or two, remove it. Otherwise today’s progressive delivery is next quarter’s flag debt. The mechanics of doing that safely live in the feature flag cleanup playbook, and the broader discipline across all eleven of our SDKs is built to make the loop boring in the best way.
The shorter version
Progressive delivery is the gradual, controlled exposure of a release to users instead of an all-at-once cutover. James Governor coined the term at RedMonk in 2018 and defined it by two pillars: release progression, which widens who can see a change at a safe pace, and progressive delegation, which hands control of that widening to the person who owns the outcome. Most write-ups cover only the first. The techniques that implement it (dark launch, canary, percentage rollout, ring-based exposure, blue-green) are chosen by the risk you’re managing, and feature flags are the control plane that makes all of them cheap by turning a release into a configuration change with a one-click rollback. The payoff lands directly on the metrics DORA tracks: smaller blast radius, faster detection, faster recovery, and the confidence to deploy more often. You can start without a platform team: ship dark, enable for staff, widen by percentage, watch, and roll back with a flag flip. Then add delegation once the loop earns trust. And remember to remove the rollout flag once the feature is fully live, before it becomes debt.
Frequently asked questions
What is progressive delivery?
Progressive delivery is the practice of exposing a release to users gradually, in controlled increments (internal staff, then a canary, then beta, then everyone) rather than all at once. RedMonk analyst James Governor coined the term in 2018, defining it by two pillars: release progression and progressive delegation (RedMonk).
What’s the difference between continuous delivery and progressive delivery?
Continuous delivery keeps a change deployable at any time. It’s about the pipeline. Progressive delivery governs who sees the change after it’s deployed. It’s about exposure. You can practise continuous delivery and still do big-bang releases; progressive delivery is the discipline added on top to widen exposure in controlled steps instead.
Is canary deployment the same as progressive delivery?
No. A canary release is one technique; progressive delivery is the broader strategy that may use canary, feature flags, ring-based exposure, dark launches, or blue-green deploys together (RedMonk). A canary tells you whether a version is healthy; progressive delivery also covers who controls the rollout and how it widens.
How do feature flags enable progressive delivery?
Feature flags decouple deploy from release: you ship code dark, then turn it on by configuration. They make exposure a value you edit, like a percentage rollout or targeting rule, rather than a redeploy. They make rollback a one-click config push. That’s what turns a rollout into a dial you can turn up slowly and reverse instantly.
What are the two principles of progressive delivery?
Release progression and progressive delegation. Release progression is widening who can see a change at a pace the business can tolerate. Progressive delegation is shifting release control from engineering and operations to the business or product owner accountable for the outcome (SD Times). Most explanations cover the first and skip the second.
Featureflip gives you the control plane for progressive delivery: percentage rollouts, targeting rules for internal and beta cohorts, sub-millisecond local evaluation, and a kill switch that streams to every connected SDK in sub-second, so widening a release, or reversing it, is a configuration change rather than a deploy. If you’d like to run the loop in this guide on your own features, start with the free Solo plan.