Menu
Feature flags (also commonly known as feature toggles) is a software engineering technique that turns select functionality on and off during runtime, without deploying new code.
The idea behind feature flags is to build conditional feature branches into code in order to make logic available only to certain groups of users at a time. If the flag is “on,” new code is executed, if the flag is “off,” the code is skipped.
A feature flag, or feature toggle, is a software development tool used to safely activate or deactivate features for testing in production, gradual release, experimentation, and operations.
Simply saying, feature toggles (sometimes also called feature flags) are on/off switches that allow us to dynamically enable and disable some parts of a system. Even during its runtime.
A 'feature flag' (or Feature Toggle) is the ability to turn features (sub-sections) of your application on/off at easily:
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.
Feature Flag is a technique to turn some functionality of your application off, via configuration, without deploying new code.
Feature flags play a key part in CI scheme where features are constantly being deployed but not necessarily "released" into production.
More info here:
-- EDIT:
Feature Flags java implementation.
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.
There are a lot of great answers here, all driving at the important, basic definition popularized in the Martin Fowler post:
They're bits of code that "[allow] teams to modify system behavior without changing code."
So we've historically thought of them as represented by the pseudo-code:
if(app_settings["beta-mode"] == "true")
showAwesomeNewGui();
else
sameOldSnoozeFeset();
That's a totally accurate way to think of it, and both Matt and Adil expand on it nicely with a variety of tactical use cases for the feature flag.
But I'd like to offer a revised definition that reflects how reality has evolved in the six years and change since dotnetdev asked the original question. I work for Rollout.io, a feature flag platform, so I've had a front-row seat for this evolution.
Simply put, feature flags aren't any longer just a way to turn bits of functionality on and off in your application. That's like answering "what is an invoice line item" by saying "it's a description and an amount of currency." True, but it doesn't drive at the broader point of the invoice itself.
Feature flags are the tactical bits of an overarching strategic solution in modern software. They're the means by which you defer important decision logic in your code until runtime when you have more information. And, perhaps most importantly, they don't just occur in isolation any longer, with a single check to see if the version number is greater than 2.7 or not; organizations that use them are typically including them as part of a comprehensive, system-wide product approach.
As others have mentioned, Facebook and LinkedIn pioneered this, but in 2018, a whole lot of organizations are doing it. They're deferring decision logic questions for runtime as part of development strategy, operations strategy (or DevOps strategy, if you want), and product strategy. Here are examples of such questions.
To have an application that defers a significant number of such decisions until runtime, you can't throw feature flags into your application in ad-hoc fashion or you'll bury yourself in technical debt. You need, these days, to have a comprehensive feature flag management strategy, which includes a few different components.
So, in the end, what are feature flags?
Well, they're an important part of a broader strategy to having an application that's adaptable to both technical and market needs.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With