| Technique | What Shifts | Rollback Speed | Best For |
|---|---|---|---|
| Canary release | A small percentage of traffic or instances get the new version | Fast; shift traffic back to the stable version | Catching regressions with real production traffic at low risk |
| Blue-green deployment | An entire parallel environment is promoted, then traffic is switched | Immediate; flip the router back to the old environment | Releases that need a clean, instant full rollback path |
| Feature flags | Code ships dark and is toggled on for specific users or segments | Instant; flip the flag off, no redeploy needed | Decoupling deploy from release and running experiments |
What Progressive Delivery Actually Means
Progressive delivery extends continuous delivery with an additional principle: a release is not something you switch on for everyone at once, it is something you dial in gradually while watching real signals. The term was popularized in DevOps and platform engineering circles to describe a family of practices, including canary releases, blue-green deployments, and feature flags, that all share the same underlying goal of controlling blast radius.
Traditional continuous delivery answers the question “can we ship this safely.” Progressive delivery adds the question “how much of production should see this right now, and what would make us stop.” That second question requires observability, defined rollback criteria, and often automation to act on those signals faster than a human could.
The Progressive Delivery Spectrum
Canary releases and blue-green deployments primarily control which infrastructure serves a request. Feature flags control which code path executes once a request arrives. Mature rollout strategies frequently combine both layers rather than choosing one exclusively.
Canary Releases: Traffic-Based Rollouts
A canary release deploys a new version alongside the stable version and shifts a small percentage of traffic to it, typically starting around one to five percent. The team watches error rates, latency, and business metrics for that slice before expanding to a larger percentage. If a regression appears, traffic shifts back to the stable version and only the small canary population was ever affected.
Canary releases require a mechanism to split traffic, commonly a service mesh, an API gateway, or a load balancer capable of weighted routing. The Google SRE Workbook discusses this kind of staged rollout as a core practice for controlling risk in large-scale production systems, tying it directly to the four golden signals: latency, traffic, errors, and saturation, since those are the metrics a canary analysis typically watches.
Automated Canary Analysis
At larger scale, teams do not eyeball dashboards for every release. Automated canary analysis tools compare metrics from the canary population against a control group and make a promote-or-rollback decision automatically based on statistical thresholds. This turns progressive delivery from a manual, judgment-heavy process into a repeatable pipeline stage, which is particularly valuable when release frequency is high.
Blue-Green Deployments: Environment-Based Cutover
Blue-green deployment takes a different approach: instead of splitting traffic between versions running side by side, it maintains two complete, identical production environments, conventionally labeled blue and green. Only one serves live traffic at a time. A new release deploys fully to the idle environment, gets validated, and then a router or load balancer switch sends all traffic to it at once. The previously live environment stays warm as an instant rollback target.
This pattern trades gradual exposure for an extremely fast, clean rollback: flipping the router back is often faster than waiting for a canary’s traffic-shift to fully reverse. The tradeoff is cost, since running two full environments simultaneously, even briefly, doubles infrastructure spend for the cutover window, and blue-green alone does not give you the fine-grained, percentage-based exposure control that a canary provides.
| Dimension | Canary | Blue-Green |
|---|---|---|
| Exposure control | Granular, percentage-based | All-or-nothing at cutover |
| Infrastructure cost | Small overlap during rollout | Two full environments during cutover |
| Typical rollback | Shift traffic percentage back | Flip router to previous environment |
| Common tooling | Service mesh, weighted load balancer | Load balancer, DNS or router switch |
Feature Flags: Decoupling Deploy From Release
Feature flags, also called feature toggles, let a team ship code to production in a dormant state and turn it on later for specific users, percentages, or segments, without a new deployment. This separates two ideas that traditional releases conflate: deploying code and releasing a feature to users. Vendors including LaunchDarkly and Flagsmith document this distinction extensively, since it is the foundation of their platforms.
Flags enable patterns that canaries and blue-green deployments cannot reach on their own, such as targeting a flag to internal employees first, running a true A/B experiment across two live variants, or instantly killing a feature that is misbehaving without touching the deployment pipeline at all. The tradeoff is flag debt: stale flags left in code long after a decision has been made add branching complexity and should be removed on a schedule.
Where Each Technique Sits in the Pipeline
Canary and blue-green operate at the infrastructure and routing layer, deciding which servers handle a request. Feature flags operate inside the application, deciding which code path runs once a request has already arrived. Combining both gives teams control over both dimensions independently.
Choosing the Right Technique for a Given Release
These three techniques are not mutually exclusive, and most mature engineering organizations use all three depending on the type of change. A backend infrastructure change with no user-facing toggle point is a natural fit for a canary or blue-green rollout. A user-facing feature that product wants to A/B test or roll out to a specific customer segment is a natural fit for a feature flag, often layered on top of a canary so the underlying code change is also exposed gradually.
This layered thinking shows up directly in how teams plan major releases. A structured launch checklist, like the one described in a twelve-step guide to deploying major software updates, treats feature flags, canary releases, and blue-green deployments as complementary blast-radius controls rather than competing options, choosing the right combination based on what is changing and how reversible it needs to be.
Organizations that have scaled through open source and platform discipline tend to bake these patterns in as defaults rather than leaving each team to reinvent them. That is exactly the argument made in case studies of companies that succeeded through disciplined open source and platform practices, where blue-green, canary, and progressive delivery show up as standard, automated defaults rather than optional extras bolted on late.
Common Mistakes and Pitfalls
Pitfall
Running a canary without a clear rollback threshold defined in advance. If nobody agreed beforehand what error rate or latency increase triggers a rollback, teams tend to rationalize marginal regressions in the moment and let a bad release ride longer than it should.
Pitfall
Letting feature flags accumulate indefinitely. Flags left in code long after the decision has shipped create branching complexity, make the codebase harder to reason about, and eventually become a source of bugs when two old flags interact in an untested way.
Pitfall
Treating blue-green as a substitute for gradual exposure. Blue-green gives a fast full rollback, but switching one hundred percent of traffic at once still exposes every user simultaneously to any bug that automated checks missed before cutover.
Pitfall
Skipping database and schema considerations. Progressive delivery techniques control application traffic well, but a schema migration that is not backward compatible can break the old version still running during a canary or blue-green transition window.
How Experienced Teams Run Progressive Delivery
Expert Practice
Teams with mature release practices define rollback criteria before a release starts, not during it, typically expressed as concrete thresholds on error rate, latency percentiles, and a small set of business metrics tied to the golden signals framework from the Google SRE Workbook. They automate the promote-or-rollback decision wherever release volume is high enough to make manual monitoring unreliable, and they keep feature flags inventoried with owners and expiry dates so flag debt gets cleaned up on a schedule rather than accumulating silently. Database schema changes are handled with expand-and-contract migrations so both old and new application versions can run against the same schema during the rollout window.
This discipline connects directly to platform-level defaults. Many organizations now bake canary steps, flag scaffolding, and rollback automation into their internal developer platform so individual teams do not have to build this tooling themselves; see our companion piece on golden paths and paved roads for developer experience for how platform teams turn progressive delivery into a default rather than a manual practice every team repeats.
The same discipline shows up in growth-stage SaaS operations. Coverage of how SaaS companies are changing how software gets delivered repeatedly points to canary and gradual rollout as the default release posture once an application has real production traffic to protect, and broader industry data in analysis of cloud software adoption trends shows canary and blue-green patterns becoming standard practice as organizations scale their release frequency.
Glossary
- Progressive delivery
- The practice of rolling out software gradually using techniques such as canary releases, blue-green deployments, and feature flags, guided by production signals rather than an all-at-once release.
- Canary release
- A rollout strategy that sends a small percentage of traffic to a new version while monitoring metrics before expanding exposure.
- Blue-green deployment
- A rollout strategy that maintains two complete production environments and switches traffic between them at cutover, keeping the previous environment as an instant rollback target.
- Feature flag
- A runtime toggle that turns a code path on or off for specific users or segments without requiring a new deployment; also called a feature toggle.
- Blast radius
- The scope of users or systems affected if a release introduces a regression; progressive delivery techniques exist to keep this scope small and controlled.
- Golden signals
- Latency, traffic, errors, and saturation, the four metrics the Google SRE Workbook recommends monitoring to judge whether a rollout is healthy.
Key Takeaways
- Progressive delivery means rolling software out gradually and watching production signals, not shipping to everyone at once.
- Canary releases control exposure through traffic percentage; blue-green deployments control exposure through environment cutover.
- Feature flags decouple deploying code from releasing it to users, enabling targeting and experimentation without redeployment.
- Define rollback thresholds before a release starts, based on latency, error rate, and business metrics, not during an incident.
- Flag debt is real; inventory flags with owners and expiry dates so stale toggles get removed on a schedule.
- Schema migrations need expand-and-contract handling so old and new app versions can share a database during rollout.
- Mature platforms bake progressive delivery into golden paths so every team gets safe rollout defaults automatically.
FAQs
What is the difference between progressive delivery and continuous delivery?
Continuous delivery focuses on making every code change safely deployable at any time. Progressive delivery adds control over how much of production sees a new release and when, using canaries, blue-green cutovers, or feature flags to expand exposure gradually while watching real metrics, rather than releasing to one hundred percent of users immediately.
Is a canary release the same as a blue-green deployment?
No. A canary release shifts a small traffic percentage to a new version running alongside the old one, expanding gradually. A blue-green deployment maintains two full environments and switches all traffic at once during cutover. Canaries offer granular exposure control; blue-green offers a faster, cleaner full rollback.
Do I need a service mesh to run canary releases?
Not strictly. A service mesh makes weighted traffic splitting easier, but API gateways, ingress controllers, and some load balancers also support percentage-based routing. What matters is having a mechanism that can shift a defined slice of traffic to the new version and shift it back quickly if metrics degrade.
What is flag debt and why does it matter?
Flag debt is the accumulation of feature flags left in code long after their rollout decision has been made. Each lingering flag adds a branch a developer must reason about, and combinations of stale flags can interact in ways nobody tested. Reviewing and removing expired flags on a schedule keeps the codebase maintainable.
Can feature flags replace canary releases entirely?
Not fully. Feature flags control which code path executes once a request reaches the application, while canaries and blue-green deployments control which infrastructure handles the request in the first place. Many teams use flags and canaries together, gaining both application-level and infrastructure-level control over a release.
What metrics should trigger an automatic rollback?
Most teams start with the four golden signals from the Google SRE Workbook: latency, traffic volume, error rate, and saturation, then add a small number of business metrics relevant to the specific feature. The key is agreeing on numeric thresholds before the release starts, not interpreting dashboards in the moment.
How does progressive delivery handle database schema changes?
Schema changes need to be backward compatible during the rollout window, since old and new application versions may run simultaneously against the same database. The common approach is an expand-and-contract migration: add new columns or tables first, migrate data, update the application, then remove old structures only after the rollout completes.
Which teams benefit most from adopting progressive delivery?
Any team shipping to production traffic that matters benefits, but the value grows with release frequency and blast radius. Teams deploying multiple times a day, or teams whose outages have direct revenue or safety impact, see the clearest return from canary releases, blue-green deployments, and feature-flagged rollouts.
- Google SRE Workbook, Google. https://sre.google/workbook/table-of-contents/
- LaunchDarkly documentation, feature flag and progressive delivery guides. https://docs.launchdarkly.com
- Flagsmith documentation, feature flag guides. https://docs.flagsmith.com
- Cloud Native Computing Foundation, CNCF resources on deployment strategies. https://www.cncf.io
