What is a "feature flag"?_问答_开发者_运维开发者技术经验分享

High Scalability mentions feature开发者_JS百科 flags here:

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

What exactly are feature flags?

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.

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:

http://code.flickr.com/blog/2009/12/02/flipping-out/

-- 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.

Who should see the new admin screen that we're rolling out, and when?
What level of membership is required to unlock this Easter egg?
When should we cutover to the new database?
Should we put a picture of a cheetah or an eagle on the checkout button to enhance conversions?

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.

Toggle points are used to switch behavior for new features.
Multiple toggle points come together to form a toggle router. A toggle router determines the state of a feature.
Toggle context provides the toggle router the necessary contextual information (e.g., specific user).
Toggle configuration provides the toggle router information about the environment.

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.

At my company we used to have an own solution for that. We created a service providing a downloadable config (.json) file for every apps. In that config we stored the flags for the features. Based on that config the app can show or hide the current feature. (For example show or hide a menu item on the sidebar).

We also created an internal admin page where we can configure the feature-flags. It worked quite good for a while but after that we would have liked to do user targeting and A/B testing. To develop by own It seemed too much effort, so we chose a third-party solution. As already mentioned here there are many solutions for that.

We chose ConfigCat because it supports customized target groups and percentage-based rollout at once. You can check the supported open-source sdks on github.

Feature flags (or feature toggles) allow you to enable features remotely on an application without needing to re-build/re-deploy the application. This allows you to deploy the code to production but not release the feature until you are ready. You are able to target specific users, so you could enable a new feature to your beta users to test.

At our company we've previously used LaunchDarkly and other suggestions from FeatureFlags.io. We've also tried to use Firebase's Remote config to try and make this work however we found it wasn't really fit for this purpose.

We ended up developing our own version called Bullet Train, which we've open sourced. It combines both Feature Flags/Toggles and Remote Config.

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

My understanding is that feature flags help you gate functionality by deciding which users receive certain features.

For example, let's say you only want your beta users to see a new feature. You would "toggle" that feature on for beta users and the rest of your users would not see it.

LDUser user = new LDUser("user@test.com");

boolean showFeature = ldClient.toggle("your.feature.key", user, false);

if (showFeature) {
     // application code to show the feature 
 }
else {
     // the code to run if the feature is off
 }

I'm testing LaunchDarkly's feature flags for some front-end JS A/B tests - seems to be working well. You can also check out this site for feature toggles and feature flag libraries.

From a coding point of view a feature flag can be as simple as an if statement which wraps around a new piece of code which you are writing. When the if statement evaluates to true (the feature flag is on) then the new code will be executed.

In a real-world example of delivering software, the if statement described above would evaluate differently depending on environment the software is running in. For example if the application is being executed on your QA server the feature flag will return true and the new feature will be seen. If it's being executed on your production server the feature flag will return false and the feature will be hidden.

From my personal experience during my career I have used feature flags in the following ways:

Decoupling code deployments from releasing of features to customers. This was my first initial use of feature flags in our development process. We used it to remove the dependency between our marketing and product team and the engineering team that was doing the development and releases. Feature flags allowed us to deploy our code weeks in advance of a launch whereas previously we were deploying code the night before a release!
Testing in production. Before we used feature flags when we released our code it was an all or nothing event, either all our customers got the feature or none of them did. We used feature flags to allow us to roll out a new feature to a small percentage of the users at a time. This allowed us to collect valuable feedback and data about a new feature without risking any potential issues to the entire customer base.
Enabling/disabling a feature per environment in the development life-cycle. We used this extensively in development for allowing a much smoother deployment process - we have a CI/CD pipeline in which the use of feature flags is vital.
Creating a kill switch. We have wrapped certain features of our application with a feature flag which allows us to 'kill' that feature in the event of any issues we are having with the application at the time. For example if we find ourselves under heavy load we are able to turn off certain non-essential features of the website to help with the issue.

You can read more about feature flags here.

You can add feature flags to your code in multiple ways.

You can create your own or use a third-party feature flag library and add your feature flag data into a config file which can be included in your deployment package.
You can create your own or use a third-party feature flag library and add your feature flag data into a config file which can be loaded at run-time.
You can use a cloud-based feature flag management service to manage all your feature flag needs for you.

Writing your own library may seem a good idea at first and usually it can start out that way. However you can soon run into issues when you want to implement the more advanced use cases of feature flags like rolling out to a percentage of users or targeting specific user groups. Another issue with creating your own feature flag implementation is if you are using multiple languages you will need to implement your code multiple times.

The best and easiest way to use feature flags is to use an online feature flag management service such as Floodgate. This way you can leverage on the platform to all the heavy lifting which then allows you to concentrate on creating the feature for your application.

Here is an example of how to add a Floodgate feature flag to an application using the .NET SDK.

using FloodGate.SDK;

var floodgateClient = new FloodGateClient("API-KEY");

var flag = floodgateClient.GetValue("a-new-feature", false);

if (flag)
{
  // Execute the code for my new feature here...
}

If you are working in a development team and you are not using feature flags and you are experiencing issues in deployments and code management within the team. Using feature flags can be a great way to resolve these issues. There is also a nice side effect of feature flags speeding up your teams development velocity.

Martin Fowler gives a very in-depth write-up of feature flags here which I recommend you to read.

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

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).