什么是“功能标志切换”以及何时使用（或不使用）？

关于存在一些问题feature flag toggles，例如：

• 如何说服开发人员开始使用功能标志切换？
• 如何使用功能标志切换？

问题：

• 实际上是什么（在DevOps的上下文中）“功能标志切换”？
• 为什么使用它们？

无需重复https://martinfowler.com/articles/feature-toggles.html的内容，因为这是关于什么功能标记切换的令人惊奇的深入解释。我将只关注DevOps方面。

根据PuppetLabs编写的2014年DevOps状态报告，有四个主要指标可衡量IT性能：

• 变更准备时间
• 释放频率
• 恢复服务的时间
• 变更失败率

这些也总体上有助于组织绩效。因此，这意味着，如果您的IT在这些指标上做得很好，那么您的底线将得到更大的收益。

持续交付通过这些指标来启用，并且在《持续交付：通过构建，测试和部署自动化实现可靠的软件发行》（Jez Humble）一书中有详细介绍。

在持续交付的情况下，有一个重要的区别将其与持续部署区分开来。决定何时发布（向客户）功能。

保持变化的尺寸更小，和部署（复制码）半生不熟功能来生产系统与功能标志切换断允许缩短更改前置时间。

当功能最终完成时，发布是企业的决定。一项新功能的发布可能需要与某些市场营销保持一致，或者业务另一部分中的发布（例如移动应用程序中的一项功能）也需要进行调整。

可以使用A / B实验将功能发布给仅部分客户群或特定人员，甚至直接发布给一般可用性（GA）。尽管通常只有在足够确定该功能可以正常工作之后才能发布到GA。可能有人争辩说，这实际上会影响释放频率。

如果没有功能标志切换，那么释放和部署之间的这种分离几乎是不可能的。

自然，当不需要部署来关闭功能时，恢复服务的时间就会大大减少。

通过使用将特征发布给一小部分客户群的特征标记，更改失败率指标也可以得到显着改善。

因此，一种称为功能标志切换的简单机制可以提高IT性能，进而提高组织整体性能。

可以在Flickr（有关该主题的最早的公开帖子中）和Etsy上找到有关如何在实际公司中完成此操作的绝佳示例。但是还有许多其他人采用了这种做法并进行了详细讨论，例如Spotify视频中著名的工程文化。

Etsy正在网上发现的多个演示中展示了其内部工具来管理功能标记 -Catapult。然后Intuit发布了一个名为Wasabi的开源工具，该工具可帮助管理功能标记。

肯·穆格（Ken Mugrage）在我的问题下方发表了一条有趣的评论，其中包含指向“ 功能切换 ”的说明性链接，其摘要如下所示：

功能切换是一项强大的技术，可让团队无需更改代码即可修改系统行为。它们分为各种用法类别，在实现和管理切换时，必须将这种分类考虑在内。切换会引入复杂性。我们可以通过使用智能切换实现方法和适当的工具来管理切换配置，来控制这种复杂性，但是我们还应该限制系统中切换的数量。

上面的摘要不仅有助于理解其含义，而且还包含一些示例以说明使用它们的原因。在进一步消化之后，似乎“功能切换”和“功能标志切换”几乎是彼此的同义词。

但是，问题（问题）的解决方案（答案）改变了问题……人们可能会问相关问题，例如：

• 使用它们的利弊是什么？这是一个有力的概念，但如果使用不当（并适当固定），也会令人生畏。
• 使用它们的例子（好的和坏的）可能是什么？我可以想到很多，其中一些是我很早以前就使用过的（甚至在DevOps出现之前就已经使用过）。