Library→Second Way: Feedback→Feature Flags
Feature Flags
Decouple deploy from release. Ship code to production without turning it on — then roll out to 1%, 10%, 100% with instant rollback at any point.
Video Lesson
A video lesson for this topic is in development. The library articles and mission exercises cover the same material in the meantime.
What are feature flags?
A feature flag (also called a feature toggle or feature switch) is a conditional in your code that controls whether a feature is active. The feature code is deployed to production, but the flag is off by default — the code runs but the feature is invisible to users.
// The feature is deployed but not yet visible
if (flags.get('new_checkout_flow')) {
return <NewCheckout />
}
return <LegacyCheckout />
Feature flags decouple deployment from release. Deployment is a technical event — code moves from repo to production. Release is a business event — users gain access to a feature. They do not have to happen at the same time.
Types of flags
Release flag
Lifetime: Days to weeks
Controls a feature under development. Enables trunk-based development — code ships before the feature is ready. Remove when fully rolled out.
e.g. new_checkout_flow, redesigned_nav
Experiment flag
Lifetime: Days to weeks
Routes traffic to different variants for A/B testing. Managed by the experiment platform. Remove when the test concludes.
e.g. checkout_button_color, price_display_v2
Ops flag
Lifetime: Permanent
A circuit breaker for a feature that may need to be disabled in production. High-risk integrations, expensive operations. Leave permanently in place.
e.g. enable_payment_provider_stripe, rate_limit_api
Permission flag
Lifetime: Permanent
Controls access by user segment — beta users, paying customers, internal staff. Part of the product, not a toggle to remove.
e.g. beta_features, premium_analytics
The dark launch pattern
The dark launch is a deployment pattern where a new code path is shipped to production and exercised — but its output is discarded rather than shown to users. It separates load testing from user impact.
0%
Code deployed, flag off
Zero user impact. Code exists in production.
0%
Dark launch — shadow traffic
New code runs alongside old. Output discarded. Load tested under real traffic.
1%
Enable for internal staff
Team members see the feature. Fast feedback on real data.
5%
Canary rollout to 5% of users
Monitor error rates and latency. Compare to control group.
100%
Full rollout
All users on new path. Flag becomes default-on.
Feature flag lifecycle
Every release flag has a lifecycle. The critical and most neglected step is removal. Flags that are never removed become flag debt.
Create
Define the flag. Default off. Add to config.
Code
Wrap new code in the flag check.
Deploy
Ship to production. Flag is off. Zero user impact.
Enable
Turn on for 1% → 10% → 50% → 100%.
Remove
Delete the flag and dead code path. Critical step.
Add a ticket to remove each release flag at the time you create it. Set an expiry date in the flag config. Review active flags in every sprint retrospective.
Risks: flag debt and complexity
Feature flags are powerful but introduce their own failure modes. The most common:
Flag debt
Flags that are never removed accumulate into a branching maze. A codebase with 50 active release flags has 2^50 possible execution paths. Most are untested.
Mitigation
Treat flag removal as a feature. Track flag age. Delete within 2 weeks of full rollout.
Testing combinations
Each flag doubles the number of states to test. With 10 flags, there are 1,024 combinations. Most teams test only the happy path.
Mitigation
Limit the number of active flags. Test the default-on and default-off states. Use feature flag testing libraries.
Configuration sprawl
Flags defined in code, environment variables, databases, and config files simultaneously. Unclear which system is authoritative.
Mitigation
Use a single flag management system. Never hardcode flag values in application code.
Further reading
Martin Fowler — Feature Toggles
martinfowler.com/articles/feature-toggles.html. The comprehensive taxonomy of flag types, patterns, and lifecycle management.
DevOps Handbook — Chapter 15
Enable Safe Deployments and Rollbacks. Feature flags as the mechanism for separating deploy from release.
Continuous Delivery — Humble & Farley
Chapter 10: Deploying and Releasing Applications. Feature flags in the context of deployment pipeline design.
LaunchDarkly Blog
launchdarkly.com/blog. Practical articles on flag management, gradual rollouts, and avoiding flag debt.