Feature flag
A feature flag is a switch in application code that turns a piece of behaviour on or off at runtime without a new deployment, so that a change can be shipped to production while hidden, then exposed to some users, then to all, or turned off again when it misbehaves. It separates deploying code from releasing a feature, so a team can deploy continuously and choose when users see what.
The longer version
In code the flag is a conditional around the new path: if the flag is on for this user, run the new checkout; otherwise run the old one. The flag's value comes from configuration outside the build, whether a file, a database row or a flag service, and it can be evaluated per environment, per user, per account or by a share of traffic. That last property is what makes flags a release tool: the new checkout goes to internal staff first, then to a small share of customers, and the metrics decide whether it widens. If it fails, the flag is turned off and the old path runs, with no deployment and no rollback.
Flags are confused with configuration and with branches. Configuration values are meant to be permanent and to vary by environment; a release flag is meant to be temporary and to vary by user, and it is deleted once the feature is fully on. A long-lived feature branch hides the change from users by keeping it out of the main branch, and pays for that with a painful merge; a flag keeps the change on main, tested and deployed, and hides it at runtime instead. The price is a second code path that has to be tested in both states.
Flags fail by accumulating. A flag meant to last a fortnight is still in the code a year later, nobody remembers which value production uses, and a test suite that runs with the flag off has never exercised the path customers are on. The combinations grow faster than anyone can test them, and a flag flipped in the wrong environment becomes an incident with no deployment to point at. The disciplines are an owner and an expiry on every flag, tests that run in both states, and an audit trail of who changed which flag when. Flags are borrowed time, and the loan is repaid by deleting them.
Common questions
What is the difference between a feature flag and a feature toggle?
Nothing: the two names describe the same runtime switch, and the settled taxonomy of release, experiment, operational and permission switches applies under either name. Some vendors reserve toggle for a plain on-off switch and flag for one with targeting rules, but that is a product's choice rather than industry usage, and the words are interchangeable in documentation and job descriptions.
How do feature flags relate to continuous deployment?
Continuous deployment sends every passing change to production automatically, which would expose half-finished features unless something hides them. The flag is that something: the code ships dark, the feature is turned on for staff, then for a share of users, then for everyone, and the deployment schedule and the release schedule stop being the same thing.
How long should a feature flag live?
A release flag lives until the feature is fully on and has held, then it is deleted along with the old path. Each flag carries an owner and an expiry date when it is created, and a flag past its expiry is a ticket. Flags that outlive the feature are the ones nobody can safely flip or remove.
What are the types of feature flags?
Four, by purpose and lifespan. Release flags hide unfinished work in production and are deleted once the feature is fully on. Experiment flags split users between variants for a measured comparison and end when the result is in. Operational flags turn off an expensive or fragile capability under load and stay for as long as the capability exists. Permission flags expose a feature to a given plan or account and are the only kind meant to be permanent.
How do you test code behind a feature flag?
In both states, on every run. The unit tests set the flag on and off explicitly rather than reading the environment, the integration suite runs the flagged path with the flag on, and the regression suite runs with production's current values so that what customers see is what was tested. A flag with two states and a suite that exercises one of them has an untested path in production.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.