Feature flags are configuration switches that allow code to be deployed to production while remaining invisible or inactive for users. They decouple deployment from release, enabling gradual rollouts, A/B tests, and instant kill switches.
Any team doing continuous delivery. Essential for trunk-based development, gradual feature rollouts, and safely testing features in production.
- Wrap new feature code in a flag check: if (featureEnabled('new_feature')) { ... }
- Deploy to production with flag OFF — code is live but inactive
- Enable for internal team first to catch obvious issues
- Enable for a beta user group or specific pilot accounts
- Enable for all users once validated
- Remove the flag from code after full rollout — accumulated flags become technical debt
Spotify ships dozens of A/B experiments simultaneously using feature flags. Each variant is a flag — some users see version A, others see B, neither knows. The Discover Weekly rollout began as a flag enabled for 1% of users, scaled to 10%, then 100% over 3 weeks as the team confirmed infrastructure could handle the load.
Please contact the author for more information on these examples at linkedin.com/in/kshitijrege
- Accumulating too many flags — stale flags that are never removed become dangerous technical debt
- Forgetting to test the disabled (flag OFF) state
- Using flags as a substitute for proper testing — flags don't make broken code safe to deploy
- Continuous Delivery — Jez Humble & David Farley