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.
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.
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.
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.
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
LDUser user = new LDUser("[email protected]");
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
}
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("[email protected]");
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
}
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...
}
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 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.
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).
发布评论
评论（12）
“功能标志”（或功能切换）是切换功能（子部分）的能力轻松地打开/关闭应用程序：
我想这个例子是，如果您需要在负载太高的情况下减少数据库查询，那么控制来减少功能集会很方便。
不过，您想要使用此功能还有许多其他原因 - 主要之一是启用 < a href="http://martinfowler.com/bliki/ContinouslyDelivery.html" rel="noreferrer">持续交付：将内容推入生产/实时状态，但禁用/切换该功能，直到它可用 完全的。我们经常使用所谓的“开发 cookie”来仅向开发团队显示未完成的功能。通过这种方式，我们可以在“取消切换”（完成）它并对公众可见之前，在多个发布/部署中测试生产中部分完成的工作（哦，是的！有更好的集成吗？）。
下面是一个简单的包，可以帮助您在 ASP.NET MVC 领域执行此操作： https://github.com/cottsak/DevCookie （全面披露：我是作者）
Fowler 还有一篇比上面链接了更多详细信息。
这篇文章（也在 Fowler 的网站上）解释了各种类型的切换策略。 DevCookie 支持基于主线/主干的策略，称为“发布切换”在文章中。
Adil 的回答强调，您可能想要的术语和原因有很多其中一些基础设施。请记住，您可能只需要其中一些东西。例如，我可能只想启用简单、敏捷的部署/交付工作流程，因此简单的基础设施就足够了。如果您随后选择想要进行全面的 #leanstartup 实验，包括 A/B、队列测试和受控滚动等 -因此，您应该考虑使用一种分析工具（例如 Heap），它可以作为一种独特的解决方案来促进这些数据驱动的开发方法。执行上述所有操作的切换基础设施将导致臃肿和不必要的复杂性。
如果您已经做到了这一点，那么您可能想看看我的一些其他想法关于主线开发、功能切换和其他愚蠢的想法，如测试、质量保证、坐下、站立、蹲伏。
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.
功能标志是一种通过配置关闭应用程序的某些功能而无需部署新代码的技术。
功能标志在 CI 方案中发挥着关键作用，其中功能不断被部署，但不一定“发布”到生产中。
更多信息请参见：
-- 编辑：
功能标记 java 实现。
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.
功能标志、功能切换、实验和受控部署是一个简单而强大的想法的同义词：将代码部署与功能部署分开。简单来说，它就是能够将您的功能投入生产，同时选择您的客户中的哪些人（如果有的话）可以看到该功能。
它们的普及在一定程度上是由 Facebook 的 Gatekeeper 推动的。 LinkedIn 的 LiX 是另一个很好的例子。
拥抱这个简单的想法为许多最佳实践奠定了基础，包括：
持续部署/交付 - 一天内将多个代码推送到生产环境。
主干/主线开发 - 功能分支应该仅为拉取请求而创建，而不是为长期功能开发而创建。
不再有发布列车让事情陷入困境。
生产中的 QA/性能测试 - 真正的 QA 和性能测试是在具有生产流量的生产基础设施上进行的。不要浪费时间构建广泛的性能实验室和临时环境。
实验 - 了解新功能如何推动您的 KPI。
出现问题时避免修补程序或代码回滚 - 修补程序和代码回滚都会带来压力，需要很长时间，并且会导致不必要的问题。相反，请关闭该功能或降低其强度。
其他人提到了开源库。完整解决方案（如 Gatekeeper 和 LiX）的一个很好的例子是 Split。我为斯普利特工作。
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.
这里有很多很好的答案，所有这些都遵循 Martin Fowler< 中流行的重要基本定义。 /a> post：
它们是一些代码，“[允许]团队在不更改代码的情况下修改系统行为。”
因此，我们历来认为它们由伪代码表示
：一种完全准确的思考方式马特和阿迪尔都很好地扩展了它，为功能标志提供了各种战术用例。
但我想提供一个修订后的定义，反映自 dotnetdev 提出最初问题以来六年来现实如何演变和变化。我在 Rollout.io 工作，这是一个功能标志平台，因此我在这一演变中占据了前排席位。
简而言之，功能标志不再只是在应用程序中打开和关闭部分功能的方法。这就像通过说“它是描述和货币金额”来回答“什么是发票行项目”。确实如此，但它并不能驱动发票本身的更广泛的点。
功能标志是现代软件中总体战略解决方案的战术部分。它们是您将代码中的重要决策逻辑推迟到运行时（当您拥有更多信息时）的方法。而且，也许最重要的是，它们不再只是孤立地发生，通过一次检查来查看版本号是否大于 2.7；使用它们的组织通常将它们作为全面的、系统范围的产品方法的一部分。
正如其他人提到的，Facebook 和 LinkedIn 率先采用了这种做法，但在 2018 年，很多组织都在这样做。他们将决策逻辑问题推迟到运行时，作为开发策略、运营策略（或 DevOps 策略，如果你愿意）和产品策略的一部分。以下是此类问题的示例。
要拥有一个将大量此类决策推迟到运行时的应用程序，您不能以临时方式将功能标志放入应用程序中，否则您将陷入技术债务之中。如今，您需要一个全面的功能标志管理策略，其中包括一些不同的组件。
那么，到底什么是功能标志呢？
嗯，它们是更广泛战略的重要组成部分，旨在拥有能够适应技术和市场需求的应用程序。
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:
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.
功能标志（也称为功能翻转或功能切换）是启用或禁用功能的开关根据需要提供潜在昂贵的功能（例如，当站点受到意外流量的冲击时）。这将为您赢得一点时间，直到您扩大规模，或者直到负载峰值消失。
以下是SWIG 文档中的示例。
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.
在我的公司，我们曾经有自己的解决方案。我们创建了一项服务，为每个应用程序提供可下载的配置 (
.json) 文件。在该配置中，我们存储了功能的标志。根据该配置，应用程序可以显示或隐藏当前功能。
（例如显示或隐藏侧边栏上的菜单项）。
我们还创建了一个内部管理页面，可以在其中配置功能标志。
它在一段时间内运行良好，但之后我们希望进行用户定位和 A/B 测试。
自己开发似乎太费力了，所以我们选择了第三方解决方案。
正如这里已经提到的，有很多解决方案。
我们选择 ConfigCat 因为它支持自定义目标组和基于百分比的一次性部署。您可以在 github 上查看支持的开源 sdks。
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.
功能标志（或功能切换）允许您在应用程序上远程启用功能，而无需重新构建/重新部署应用程序。
这允许您将代码部署到生产环境，但在准备好之前不要发布该功能。
您可以定位特定用户，因此可以为测试用户启用新功能进行测试。
在我们公司，我们之前使用过 LaunchDarkly 以及来自 FeatureFlags.io。我们还尝试使用 Firebase 的远程配置来尝试实现此功能我们发现它并不真正适合这个目的。
我们最终开发了自己的版本，名为 Bullet Train，并已将其开源。它结合了功能标志/切换和远程配置。
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.
功能标志有多种用途。
总体思路是将哪些用户看到哪些功能的控制权委托给某些远程仪表板或某种后台办公室。
一旦在代码中标记了某个功能，您现在可以使用多种方法来确定哪个用户在您的应用程序中看到它：
1. 开/关 - 向所有用户显示该功能或不向任何用户显示该功能。
2. 逐步发布 - 仅向一部分用户展示该功能，然后逐渐向所有用户展示。
3. 定位 - 根据特定用户的属性或特征向该用户显示该功能。
帮助控制功能标志（布尔值）和功能配置（字符串、数字等）的工具通常称为功能管理平台
有一个很棒的功能管理服务，名为 Configz.io
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
我的理解是，功能标志可以通过决定哪些用户接收某些功能来帮助您控制功能。
例如，假设您只希望测试版用户看到新功能。您可以为测试版用户“切换”该功能，而其他用户将看不到它。
我正在测试 LaunchDarkly 的功能标志 进行一些前端 JS A/B 测试 - 似乎运行良好。您还可以访问此网站了解功能切换和功能标志库。
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.
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.
从编码的角度来看，功能标志可以像一个
if语句一样简单，它包装了您正在编写的一段新代码。当if语句的计算结果为 true（功能标志打开）时，将执行新代码。在交付软件的实际示例中，上述
if语句将根据软件运行的环境进行不同的评估。例如，如果应用程序正在您的 QA 服务器上执行，则功能标志将返回true，新功能将会被看到。如果它在生产服务器上执行，功能标志将返回 false，并且该功能将被隐藏。根据我职业生涯中的个人经验，我通过以下方式使用功能标志：
将代码部署与向客户发布功能分离。这是我在开发过程中第一次首次使用功能标志。我们用它来消除营销和产品团队与进行开发和发布的工程团队之间的依赖。功能标志允许我们在发布前几周部署代码，而以前我们是在发布前一天晚上部署代码！
在生产中进行测试。在我们使用功能标志之前，当我们发布代码时，这是一个全有或全无的事件，要么我们所有的客户都获得了该功能，要么没有人获得了该功能。我们使用功能标志来允许我们一次向一小部分用户推出新功能。这使我们能够收集有关新功能的宝贵反馈和数据，而不会冒给整个客户群带来任何潜在问题的风险。
在开发生命周期中启用/禁用每个环境的功能。我们在开发中广泛使用了这一点，以实现更顺畅的部署过程 - 我们有一个 CI/CD 管道，其中使用功能标志至关重要。
创建终止开关。我们使用功能标志封装了应用程序的某些功能，该标志允许我们在应用程序出现任何问题时“终止”该功能时间。例如，如果我们发现自己负载过重，我们可以关闭网站的某些非必要功能来帮助解决问题。
您可以在此处阅读有关功能标志的更多信息。
您可以通过多种方式向代码添加功能标志。
编写自己的库一开始似乎是个好主意，通常可以这样开始。但是，当您想要实现功能标志的更高级用例（例如向一定比例的用户推出或针对特定用户组）时，您很快就会遇到问题。创建自己的功能标志实现的另一个问题是，如果您使用多种语言，则需要多次实现代码。
使用功能标记的最佳且最简单的方法是使用在线功能标记管理服务，例如 Floodgate。通过这种方式，您可以利用该平台来完成所有繁重的工作，然后您可以专注于为您的应用程序创建功能。
以下是如何使用 .NET SDK 将 Floodgate 功能标志添加到应用程序的示例。
如果您在开发团队中工作并且没有使用功能标志，并且您在团队内的部署和代码管理中遇到问题。使用功能标志可能是解决这些问题的好方法。功能标志还有一个很好的副作用，可以加快团队的开发速度。
Martin Fowler 在此处给出了我推荐的功能标志的非常深入的文章你去读。
From a coding point of view a feature flag can be as simple as an
ifstatement which wraps around a new piece of code which you are writing. When theifstatement evaluates to true (the feature flag is on) then the new code will be executed.In a real-world example of delivering software, the
ifstatement 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.
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.
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.
在我的公司，我们对 SaaS 应用程序中引入的每个新功能都使用功能标志。除了性能方面的好处之外，它还允许我们逐步推出新功能 - 首先向高级用户引入新功能，从他们那里获取反馈并进行临时改进，然后再将其推出给所有用户。
它还允许我们为个人用户定制产品——高级用户想要所有功能；简单的用户可能只想要基本的东西，并且可能会对所有强大的复杂功能感到困惑。它还允许我们的销售团队进行追加销售。
当然，正如其他人指出的那样，如果我们发现某个功能导致性能下降，我们可以简单地关闭该功能（无论是针对所有客户端还是针对导致问题的一个客户端）。
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).