What is a “feature flag”?

Question

High Scalability mentions feature flags here:

5 things toxic to scalability, \"5. Lack of Feature Flags\"

What exactly are feature flags?

Answer 1

A 'feature flag' (or Feature Toggle) is the ability to turn features (sub-sections) of your application on/off at easily:

• perhaps via a re-deploy, or
• some internal page where pages/features can be toggled live.

I guess the example there was that it's handy to have the control to reduce the feature-set somewhat if you need to, say, reduce db queries if the load is too high.

There are heaps of other reasons you would want to use this though - one of the main being enabling Continuous Delivery: pushing things into production/live yet having the feature disabled/toggled until it's completed. We often use what we call a 'dev cookie' to show uncompleted features to just the dev team. This way we can test partially completed work in production (oh yeh! is there better integration?) over multiple releases/deployments before we 'untoggle' (completed) it and it becomes visible to the public.

Here's a simple package that helps you do this in ASP.NET MVC land: https://github.com/cottsak/DevCookie (full disclosure: I'm the author)

Fowler also has a much longer article than the one linked above with a lot more details.

This post (on Fowler's site also) explains the various types of toggle strategies. DevCookie supports the mainline/trunk-based strategy and is called a "Release Toggle" in the article.

Adil's answer highlights that there are many terms and reasons why you might want some of this infrastructure. Keep in mind you may only need some of these things. For example, I may only want to enable a simple, and agile deployment/delivery workflow and so a simple infrastructure will suffice. If you then choose you want to move into full #leanstartup experimentation with A/B, cohort testing and things like controlled roll-out, you should consider an analytics tool (e.g. Heap) which facilitates those data-driven development methodologies as a distinct solution. A toggle infrastructure that does all of the above will lead to bloat and unnecessary complexity.

If you made it this far, then you might like to check out some of my other thoughts on Mainline Development, feature toggling, and other silly ideas like TEST, QA, SIT, STAND, CROUCH.

Answer 2

Feature Flags are used for several purposes. The general idea is to delegate control over which user sees what feature to some remote dashboard or back-office of some sort.

Once a feature is flagged in the code you can now use several methods to determine which user sees it in your application: 1. On/Off - show the feature to all or none of your users. 2. Gradual Release - show the feature only to a percentage of your users, then gradually show it to all users. 3. Targeting - show the feature to specific users based on properties or characteristics of that user.

Tools that help with controlling Feature Flags (booleans) and Feature Configurations (strings, numbers, etc) are usually called Feature Management Platforms There is a great service for Feature Management called Configz.io

Answer 3

At my company we use feature flags for every new feature we introduce in our SaaS app. Apart from the benefits to performance it also allows us to roll out new features gradually - introducing new features to power users first, getting feedback from them and improvising it before we can roll it out to all users.

It also allows us to customize offering to individual users - power users want all features; simple users may just want the basic stuff and may get confused by all the powerful complex features. It also allows our sales team to up-sell.

And of course as others have pointed out, if we find a feature is causing a performance degradation, we can simply turn off that one feature (either for all clients or for the one client who is causing an issue).

Answer 4

Feature Flags basically gives you the ability to turn on and off a feature without making any changes on the code or releasing a new version. It's an important solution especially for mobile application developers since they have no control on users to update their application to a new version.

There are several companies giving this service for mobile application developers.

• apptunnel.com
• apptimize.com
• launchdarkly.com

Answer 5

A feature flag (also known as feature flipping or feature toggle) is a switch to enable or disable a potentially expensive feature as needed (like, say, when a site is being hammered with unexpected traffic). This'll buy you a little time until you scale up, or until the load spike goes away.

Here's an example from the SWIG documentation.

Answer 6

Feature Flags, feature toggles, experiments, and controlled rollouts are synonyms for a simple yet powerful idea: separate code deploys from feature rollouts. In plain speak, it’s the ability to push your feature’s commits to production while choosing who amongst your customers - if anyone at all - gets to see that feature.

They were popularized in part by Facebook's Gatekeeper. LinkedIn's LiX is another good example.

Embracing this simple idea lays the foundation for many best practices, including:

Continuous Deployment/Delivery - multiple code pushes to production in a day.

Trunk/Mainline Development - feature branches should be created only for pull requests, not for long lived feature development.

No More Release Trains to bog things down.

QA/Perf Testing in Production - real QA and performance testing is on production infrastructure with production traffic. Don’t waste time building extensive performance labs and staging environments.

Experimentation - know how a new feature moves the needle on your KPIs.

Avoiding Hotfixes or Code Rollbacks when Problems Happen - both hotfixes and code rollbacks are stressful, take a long time, and lead to more problems than necessary. Instead, turn the feature off or ramp it down.

Others have mentioned open source libraries. A good example of a full solution - like Gatekeeper and LiX - is Split. I work for Split.