In this post
What are feature flags used for?
Common uses are hiding unfinished work, gradual rollouts to a small share of users, testing a change with one group, and a kill switch that disables a feature quickly if it misbehaves.
How do they change release practice?
They separate deployment, which is a technical step, from release, which is a business decision. Code can reach production often and safely, and the moment a feature becomes visible is chosen separately.
What are the risks?
Each flag adds a branch in the code that must be tested in both states. Old flags pile up, and an unexpected toggle of a forgotten flag can revive dead code. Flags that guard security or payments need especially careful control of who can change them.
How do you manage flags well?
Give every flag an owner, a purpose and a removal date, and remove it once the rollout is complete. Keep a list of what exists, and treat permanent configuration separately from temporary release flags.
How do you test with flags?
Test the main combinations that can occur in production, not every possible combination, and check that turning a flag off returns the old behaviour cleanly. Log flag state with errors so you can tell which path failed.
Sources and further reading
- Hodgson, P. Feature Toggles (aka Feature Flags). martinfowler.com.
- OpenFeature. openfeature.dev (an open standard for flag evaluation).
IICTP is an independent technical credentialing body.