Feature Flags and Progressive Rollouts
The default way to ship is also the riskiest: merge, deploy, and now every user is running the new code at once. If something’s wrong, everyone finds out at the same time, and the only way back is a rollback — which fixes the symptom but throws away the deploy. Feature flags and progressive rollouts exist to separate two things that a plain deploy bundles together: shipping the code, and turning the feature on.
This guide covers what a feature flag actually decouples, the handful of different jobs flags do under one name, how a percentage or canary rollout extends the idea to your whole user base, and the ongoing cost of flags that nobody remembers to remove.
What a feature flag actually decouples
A feature flag is a conditional check in your code — ‘if this flag is on, run the new path; otherwise, run the old one’ — controlled by a value you can change without a new deploy. The thing it buys you is separating deploy from release: the new code can be live in production, fully deployed, while being invisible to every user until you flip the flag.
That separation is what makes a risky feature safe to ship. If the flagged code has a problem, turning it off is instant and doesn’t require rolling back a deploy, re-running a pipeline, or losing whatever else shipped alongside it.
Four kinds of flags, not one
‘Feature flag’ covers several genuinely different jobs, and Martin Fowler’s breakdown of the idea is worth knowing because each kind has a different lifespan. A release flag hides an in-progress feature until it’s ready, and gets deleted once the feature ships fully — it should live for days or weeks, not months.
An experiment flag runs an A/B test and is removed once the test concludes. An ops flag is a kill switch for a risky operational path — something you might flip on and off for years, like a circuit breaker around a flaky third-party integration. A permission flag controls access by plan or role, and is often permanent by design, tied to the product rather than to a rollout.
Percentage and canary rollouts
Turning a flag on for everyone at once still has the same blast radius as a plain deploy — it’s just delayed. A percentage rollout instead turns a flag on for a small slice of users first, then a wider one, then everyone, watching error rates and key metrics at each step before widening it further. Kubernetes’ rolling update strategy applies the same idea at the infrastructure level, replacing old pods with new ones gradually rather than all at once.
A canary rollout is the same idea with a specific target: a small, deliberately chosen segment — internal users, one region, one customer tier — gets the change first, as an early warning system before it reaches everyone else.
Flag debt is a real, ongoing cost
A flag that’s meant to live for two weeks while a feature rolls out has a way of still being in the codebase a year later, its condition tangled into three other conditions nobody wants to untangle. This is flag debt, and it’s a genuine cost: every live flag is a branch in your code that has to be understood, tested and reasoned about, whether or not anyone remembers why it exists.
The fix isn’t avoiding flags — it’s treating removal as part of the job a release flag was created to do, not an optional cleanup step. A flag with no owner and no removal date is the one most likely to still be there next year.
Frequently asked questions
How is a feature flag different from a CI/CD rollback?
A rollback undoes an entire deploy, taking back everything that shipped in it, including unrelated fixes. A feature flag turns off one specific feature without touching the deploy at all — the code stays live, just inactive — which is faster and far more targeted when only one part of a release is the problem.
Do you need a dedicated feature-flag service to get started?
No. A single boolean read from a config file or environment variable is a real feature flag and is enough for a small team’s first release flags. Dedicated services earn their cost once you need percentage rollouts, per-user targeting, or flags managed by non-engineers.
What is flag debt?
The accumulated cost of feature flags that outlived their purpose — usually release flags left in the code long after the feature fully shipped. Each one adds a branch of logic that has to be maintained and understood, even though the answer (‘is this on’) has been fixed and settled for months.
What’s the difference between a canary rollout and a percentage rollout?
A percentage rollout widens exposure by an arbitrary slice of the whole user base — a small percent, then a larger one, then everyone. A canary rollout targets a specific, deliberately chosen group first — internal staff, one region — rather than a random percentage, so the people seeing it first are the ones best placed to notice something’s wrong.
Explore the full desk on the home page →
Sources: Martin Fowler — Feature Toggles (aka Feature Flags) · Kubernetes Docs — Deployments (Rolling Updates) — all accessed 4 August 2026.
One concierge, many modes
Learn it, apply it, go further — this page, your way.
Learn it (4)
Apply it (4)
Go further (4)
Terms used on this page
Tap any term for this site’s own definition — no search, no leaving the page.