Feature Flags and Progressive Delivery: Shipping Constantly Without Shipping Incidents
Separating deploy from release is the single highest-leverage change most delivery organisations can make. It also creates a debt problem if you skip governance.
There is a specific kind of organisational fear that shapes engineering culture: the fear of release day. It produces change-freeze calendars, Friday deployment bans, four-hour release calls, and an inverse relationship between how carefully a release is planned and how badly it goes.
Progressive delivery removes the premise. If deploying code and exposing behaviour are separate events, release stops being a cliff edge and becomes a dial.
The core idea
Deployment is a technical act: new code exists in production. Release is a product act: some set of users experiences new behaviour. Feature flags decouple them. Once decoupled, you can deploy continuously, expose gradually, observe honestly and revert instantly — without a rollback deployment, without a hotfix branch, and without waking anyone up.
A flag taxonomy you must define on day one
Every unmanaged flag estate we have untangled had one root cause: all flags were treated identically. They are not the same thing and they do not have the same lifecycle.
| Type | Purpose | Lifespan | Owner |
|---|---|---|---|
| Release flag | Gradual rollout of new behaviour | Days to weeks — must be removed | Engineering |
| Experiment flag | A/B or multivariate testing | Length of the experiment | Product / growth |
| Operational flag | Kill switches, load shedding, degradation | Long-lived by design | Platform / SRE |
| Permission flag | Entitlements and plan gating | Permanent — belongs in the product model | Product |
The critical rule: permission flags are not feature flags. If entitlement logic lives in your rollout tool, your billing behaviour is now controlled by a system with no audit trail and an intern's access.
Progressive delivery in practice
Stage 1 — Internal exposure
Enable for the team and internal users. This catches the embarrassing class of defect at zero customer cost, and it forces the feature to be genuinely usable rather than demo-usable.
Stage 2 — Canary
One to five percent of traffic, ideally segmented so you can compare like with like. Watch guardrail metrics rather than the feature's own success metric — the point of a canary is to detect harm, not to prove value.
Stage 3 — Ramp
Increase in steps, pausing long enough at each level for signal to accumulate. Ramping faster than your metrics can resolve is a deployment with extra steps.
Stage 4 — Full release and cleanup
Reach one hundred percent, then remove the flag and the dead branch. This step is skipped almost universally, and skipping it is how a codebase acquires two hundred conditional paths nobody can reason about.
Guardrail metrics and automated rollback
Automated rollback requires agreement before the incident, not judgement during it. Define a small guardrail set that applies to every rollout:
- Error rate and error budget burn
- Latency at the 95th and 99th percentiles
- Core conversion or task-completion rate
- Client-side exception rate
- Support contact rate for the affected journey
Attach thresholds and an evaluation window, then let the system disable the flag automatically when breached. The value is not the automation itself — it is that the decision was made calmly, in advance, by people who were not being paged.
The debt problem, and the only thing that solves it
Flag debt is real: stale flags create untested code paths, combinatorial state explosion, confusing behaviour differences between users, and eventually a codebase where nobody can say what production actually does. Tooling does not fix this. Policy does.
- Every release flag has a named owner and a mandatory expiry date at creation.
- A weekly automated report lists expired flags; expiry breaches become tickets, not warnings.
- Flag removal is part of the feature's definition of done, not a follow-up epic.
- Static analysis flags references to keys that no longer exist in the management system, and vice versa.
- Cap concurrent flags per service. A hard limit forces cleanup far more reliably than good intentions.
Testing in a flagged world
You cannot test every combination, and pretending otherwise stalls delivery. Test the states that will actually exist: current production, the fully released state, and any explicitly supported intermediate combination. Run your automated suite against both the on and off state of any flag currently ramping. Anything beyond that is combinatorics theatre.
The organisational payoff
Teams that adopt this properly stop negotiating release windows. Deployment frequency rises, change failure rate falls because exposure is limited, and mean time to recovery collapses because recovery is a configuration change rather than a build. Most importantly, the conversation about a risky feature changes from "are we confident?" to "what percentage, and what will make us stop?" — which is a question engineering can actually answer.
Frequently Asked Questions
What is progressive delivery?
Releasing changes gradually — to internal users, then a small percentage of traffic, then everyone — with automated monitoring and rollback. Deployment becomes separate from release, so shipping code is no longer the same as exposing behaviour.
Do feature flags create technical debt?
Unmanaged ones certainly do. A flag without an owner and an expiry date becomes permanent conditional logic that nobody dares remove. Governance, not tooling, is what prevents this.
How is a feature flag different from a config toggle?
A config toggle changes environment behaviour; a feature flag targets specific users or traffic segments at runtime and is designed to be temporary. Confusing the two is how permanent flags appear.
Can we use flags for experimentation and rollout with the same system?
Technically yes, but treat them as different flag types with different lifecycles. Release flags are short-lived and removed; experiment flags need statistical rigour; permission flags are permanent by design.
What does a safe automated rollback need?
A defined guardrail metric set, a baseline, a statistically meaningful evaluation window and an automated kill switch. Without agreed thresholds, rollback becomes a judgement call made under pressure.