What is a "feature flag"?

High Scalability mentions feature flags here:

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

What exactly are feature flags?

71221 次浏览
小开
最佳答案

“功能标志”(或 功能切换)是能够轻松地打开或关闭应用程序的功能(子部分) :

  • 也许通过重新部署，或者
  • 一些可以实时切换页面/特性的内部页面。

我猜想这里的例子是，如果需要减少数据库查询(比如说，如果负载过高) ，使用控件来减少特性集是很方便的。

有一些 还有很多其他原因你会想要使用这个功能——其中一个主要功能就是启用 持续交付: 将东西推入生产/现场，同时禁用/切换这个功能，直到它完成。我们经常使用所谓的“开发 cookie”来向开发团队显示未完成的特性。这样我们就可以在生产环境中测试部分完成的工作(哦耶！是否存在更好的整合?)在我们‘解开’(完成)它之前，它会变得对公众可见。

这里有一个简单的软件包，可以帮助你在 ASP.NET MVC 领域做到这一点: https://github.com/cottsak/DevCookie(完全公开: 我是作者)

Fowler 也有 更长的文章比上面链接的一个更多的细节。

这篇文章(也发表在 Fowler 的网站上)解释了切换策略的各种类型。DevCookie支持基于主线/干线的策略，在本文中称为“ 释放开关”。

Adil 的回答 强调了有许多术语和理由可以解释您为什么需要这种基础设施。记住，你可能只需要其中的一些东西。例如，我可能只想启用一个简单而敏捷的部署/交付工作流，因此一个简单的基础设施就足够了。如果你选择进入完整的 # 精益创业实验，包括 A/B、队列测试和控制推出等，你应该考虑一个分析工具(例如 堆) ，它可以促进这些数据驱动的开发方法作为一个独特的解决方案。如果切换基础设施执行上述所有操作，将导致臃肿和不必要的复杂性。

如果你已经走到这一步了，那么你可能想看看我的 其他关于主线开发，功能切换的想法，以及其他愚蠢的想法，如测试，质量保证，坐，站，蹲。

小开

功能标志(也称为功能翻转或 功能切换)是一个开关，可以根据需要启用或禁用一个潜在的昂贵功能(比如，当一个站点正在遭受意想不到的流量时)。这会给你争取一点时间，直到你扩大规模，或者直到负载峰值消失。

这是 SWIG 文档中的一个例子。

小开

FeatureFlag 是一种通过配置关闭应用程序某些功能的技术，无需部署新代码。

特性标志在 CI 方案中起着关键的作用，在 CI 方案中，特性不断地被部署，但不一定“发布”到生产环境中。

更多信息请点击:

编辑:

Feature Flags java 实现 。

小开

我的理解是，特性标志通过决定哪些用户接收某些特性来帮助您关闭功能。

例如，假设您只想让您的 beta 用户看到一个新特性。你可以为 beta 用户“切换”这个特性，而其他用户看不到它。

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
}

我正在测试 LaunchDark 的特色旗帜的一些前端 JS A/B 测试-似乎工作得很好。你也可以查看 这个网站的功能切换和功能标志库。

小开

功能标志、功能切换、实验和控制推出是一个简单但强大的想法的同义词: 从功能推出中分离代码部署。简单地说，就是推动你的特性投入生产的能力，同时选择你的客户中的哪些人——如果有的话——可以看到这个特性。

它们在一定程度上是由 Facebook 的守门人推广的，LinkedIn 的 LiX 是另一个很好的例子。

接受这一简单的想法为许多最佳做法奠定了基础，其中包括:

持续部署/交付 -多个代码在一天内推送到生产环境。

Trunk/Mainline Development -特性分支应该只为请求创建，而不是为长期的特性开发创建。

没有更多的发布列车 使事情陷入困境。

生产中的 QA/Perf 测试 -真正的 QA 和性能测试是在有生产流量的生产基础设施上进行的。不要浪费时间构建大量的性能实验室和分段环境。

实验 -了解新特性如何在 KPI 上移动指针。

当问题发生时避免修补程序或代码回滚 -修补程序和代码回滚都是有压力的，需要很长时间，并导致比必要的更多的问题。相反，应该关闭或者降低这个特性。

其他人提到了开源库。完整解决方案的一个很好的例子是 分开，比如 Gatekeep 和 LiX。我为斯普利特工作。

小开

FeatureFlags 基本上可以让您在不对代码做任何更改或发布新版本的情况下开启或关闭某个特性。 这是一个重要的解决方案，特别是对于移动应用程序开发人员来说，因为他们无法控制用户更新他们的应用程序到一个新版本。

有几家公司为移动应用程序开发人员提供这项服务。

小开

在我的公司，我们在 SaaS 应用程序中引入的每个新特性都使用特性标志。除了对性能的好处之外，它还允许我们逐步推出新特性——首先向高级用户介绍新特性，从他们那里获得反馈，并在推广到所有用户之前对其进行即兴改进。

它还允许我们为个人用户定制产品——高级用户想要所有的功能; 简单用户可能只想要基本的东西，可能会被所有强大的复杂功能搞糊涂。这也使我们的销售团队能够超额销售。

当然，正如其他人指出的那样，如果我们发现某个特性导致性能下降，我们可以简单地关闭该特性(对于所有客户端或导致问题的一个客户端)。

小开

这里有很多很棒的答案，都是基于 Martin Fowler文章中流行的重要的基本定义:

它们是“[允许]团队在不改变代码的情况下修改系统行为”的代码片段

因此，我们历史上一直认为它们代表着伪代码:

if(app_settings["beta-mode"] == "true")
showAwesomeNewGui();
else
sameOldSnoozeFeset();

这是一种完全准确的思考方式，Matt 和 Adil 都很好地利用特性标志的各种战术用例对其进行了扩展。

但是我想提供一个修改过的定义，它反映了自从 Dotnetdev 提出最初的问题以来，现实是如何在六年中发生变化的。我为 出发工作，这是一个特色旗帜平台，所以我在这次演变中坐在第一排。

简单地说，功能标志不再仅仅是在应用程序中打开和关闭功能的一种方式。这就像回答“什么是一个发票项目”通过说“它是一个描述和数额的货币。”是的，但是它并没有从发票本身的更广泛的角度出发。

特性标志是现代软件中总体战略解决方案的战术位。它们是将代码中的重要决策逻辑推迟到运行时的方法，直到您拥有更多信息。而且，也许最重要的是，它们不再是孤立地出现，不再是单独地检查版本号是否大于2.7; 使用它们的组织通常将它们作为全面的、系统范围的产品方法的一部分。

正如其他人提到的，Facebook 和 LinkedIn 是这方面的先驱，但在2018年，很多组织都在这么做。他们将决策逻辑问题推迟到运行时作为开发策略、运营策略(或者 DevOps 策略，如果您愿意的话)和产品策略的一部分。下面是这些问题的例子。

  • 谁应该看到我们正在推出的新管理屏幕，什么时候？
  • 解开这个复活节彩蛋需要什么级别的会员资格？
  • 我们应该什么时候切换到新的数据库？
  • 我们应该在结账按钮上放一张猎豹或者鹰的图片来提高转换率吗？

要让一个应用程序将大量这样的决策推迟到运行时，就不能以特定的方式向应用程序中添加特性标志，否则就会陷入技术债务中。现在，您需要一个全面的特性标志管理策略，其中包含一些不同的组件。

  • 切换点 用于切换新特性的行为。
  • 多个切换点聚集在一起形成一个 切换路由器。切换路由器决定一个功能的状态。
  • 切换上下文 为切换路由器提供必要的上下文信息(例如，特定用户)。
  • 切换配置 提供有关环境的切换路由器信息。

那么，到底什么是特征标志呢？

对于一个能够同时适应技术和市场需求的应用程序来说，它们是更广泛战略的重要组成部分。

小开

特性标志(或特性开关)允许您在应用程序上远程启用特性，而无需重新构建/重新部署应用程序。 这允许您将代码部署到生产环境中，但是在您准备好之前不会发布这个特性。 您能够针对特定的用户，因此您可以为您的 beta 用户启用一个新特性来进行测试。

在我们公司，我们以前使用过 发射黑暗和其他来自 国旗特辑的建议。我们也尝试使用 Firebase 的远程配置来尝试使这个工作，但是我们发现它并不真正适合这个目的。

我们最终开发了自己的版本，称为 子弹头列车，我们已经开源。它结合了 Feature Flags/Toggles 和 Remote Config。

小开

特征标志有几种用途。 总体思路是将控制权委托给某个远程仪表板或某种后台办公室，让用户查看某个特性。

一旦在代码中标记了一个特性，你现在可以使用几种方法来确定哪个用户在你的应用中看到了它: 1. 开/关-向所有或全部用户显示该功能。 2. 渐进式释放-只向一定比例的用户显示该功能，然后逐渐向所有用户显示。 3. 瞄准目标-根据特定用户的属性或特征向特定用户显示特性。

帮助控制特性标志(布尔值)和特性配置(字符串、数字等)的工具通常被称为 < strong > 特性管理平台 有一个很棒的功能管理服务叫做 < a href = “ https://Configz.io”rel = “ nofollow norefrer”> Configz.io

小开

在我的公司，我们曾经有一个自己的解决方案。我们创建了一个为每个应用程序提供可下载配置(.json)文件的服务。 在该配置中，我们存储了特性的标志。基于该配置，应用程序可以显示或隐藏当前的功能。 (例如，显示或隐藏侧边栏上的菜单项)。

我们还创建了一个内部管理页面，在那里我们可以配置特性标志。 它工作了一段时间相当不错，但在那之后，我们希望做用户定位和 A/B 测试。 自己开发似乎太费力了，所以我们选择了第三方解决方案。 正如前面提到的，有很多解决方案。

我们选择 ConfigCat是因为它同时支持定制的目标群体和基于百分比的展示。您可以在 Github上检查受支持的开源 sdks。

小开

从编码的角度来看，一个特性标志可以像一个 if语句一样简单，它包围了你正在编写的一段新代码。当 if语句的计算结果为 true (特性标志打开)时，将执行新代码。

在交付软件的实际示例中，上面描述的 if语句将根据软件运行的环境进行不同的评估。例如，如果应用程序正在您的 QA 服务器上执行，那么功能标志将返回 true，新功能将显示出来。如果它是在您的生产服务器上执行的，那么功能标志将返回 false 并且功能将被隐藏。

根据我在职业生涯中的个人经验，我使用特征标志的方式如下:

  1. 从向客户发布特性中解耦代码部署。这是我在开发过程中第一次使用特性标志。我们使用它来消除我们的市场营销和产品团队与负责开发和发布的工程团队之间的依赖关系。特性标志允许我们在发布前几周部署代码，而之前我们是在发布前一天晚上部署代码！

  2. 生产测试。在我们使用特性标志之前，当我们发布代码的时候，这是一个全有或全无的事件，要么我们所有的客户都得到了特性，要么他们都没有。我们使用特性标志来允许我们一次向一小部分用户推出一个新特性。这使我们能够收集有关新特性的有价值的反馈和数据，而不会给整个客户群带来任何潜在的问题。

  3. 在开发生命周期的每个环境中启用/禁用一个特性。我们在开发中广泛地使用了这种方法，以便更加顺利地进行部署——我们有一个 CI/CD 流水线，其中特性标志的使用是至关重要的。

  4. 创建一个自杀开关。我们已经用一个特性标志包装了应用程序的某些特性，这个标志允许我们在当时应用程序出现任何问题时“杀死”该特性。例如，如果我们发现自己在沉重的负载，我们能够关闭网站的某些非必要的功能，以帮助解决这个问题。

你可以在这里阅读更多的 关于特色旗帜。

可以通过多种方式向代码中添加特性标志。

  1. 您可以创建自己的或使用第三方特性标志库，并将特性标志数据添加到可以包含在部署包中的配置文件中。
  2. 您可以创建自己的或使用第三方特性标志库，并将特性标志数据添加到可以在运行时加载的配置文件中。
  3. 您可以使用基于云的功能标志管理服务来管理您所有的功能标志需求。

一开始，编写自己的库可能看起来是个好主意，而且通常可以这样开始。然而，当您希望实现特性标志的更高级用例时，您可能很快就会遇到问题，比如向一定百分比的用户推广或针对特定用户组。创建自己的特性标志实现的另一个问题是，如果使用多种语言，则需要多次实现代码。

使用特征标志的最好和最简单的方法是使用在线特征标志管理服务，如 水闸。通过这种方式，您可以利用平台完成所有繁重的工作，从而使您能够集中精力为应用程序创建特性。

下面是如何使用.NETSDK 向应用程序添加 Floodgate 特性标志的示例。

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

如果您在一个开发团队中工作，但没有使用特性标志，并且在团队中的部署和代码管理中遇到了问题。使用特性标志可能是解决这些问题的一个很好的方法。特性标志还有一个很好的副作用，那就是加快了团队的开发速度。

Martin Fowler 给出了一篇非常深入的特性标志 给你的文章，我推荐您阅读。


提交答案