什么是Feature flags

通俗点讲，Feature flags 是一种将 "功能开关+ 灰度发布 + 远程配置 + ab测试 + 版本控制 + 持续交付 + 订阅管理 + 等等" 多个能力融为一体的技术。

独立解释，Feature flags 是种软件开发技术，旨在运行时控制功能模块(Feature)的发布与回滚。解耦Feature的部署与发布，解耦大版本发布为多个Feature独立发布，从而实现：

1. 在生产环境测试
2. 基于Feature细粒度地渐进式发布、灰度发布
3. 无需重新部署，基于Feature的秒级版本回滚
4. 随时部署上线，准备好时再发布

缓解发布压力，降低发布风险，提高交付质量，提前试错时间，加快反馈速度

Feature Flags从开关特性出发，又衍生出了其他的几个常用的功能特性：

1. AB测试
2. 远程配置与下发
3. 订阅计划管理
4. 版本管理

直白点讲，根据敏捷开关与海外独角兽(launchdarkly)对客户的统计，使用 feature flags 后，企业的平均交付频率提高了9倍，迭代速度提高了2倍以上， 产品GTM成功率明显提升。

此文章将以如下几个方面详细介绍Feature flags（且持续更新中）：

1. 基础特性与价值
2. 应用场景（尽量链接更详细的相关文章与代码示例）
3. Feature Management平台
4. 自研 & 3方工具

Feature Flags的基础特性

To 研发效能 - 交付更早、更快、更安全

通过在生产环境对Feature进行测试、千人千面的渐进式发布、无需部署即可秒级版本回滚，缓解发布压力，降低发布风险，让发布更自信。通过提高部署频率，减少每次变更内容，降低合并风险与Code review难度，提升软件质量、提前发布时间。

To 团队协同效能

将大版本迭代解耦至多个功能特性（Feature）的独立迭代，多团队针对相关Feature进行任务分配、执行与追溯。赋予所有团队控制软件功能持续交付的能力。串联功能特性的需求制定、开发、测试、部署、发布等环节，让开发紧密结合产品与市场反馈，共同创收。

To 技术管理者

基于软件层面使开发与迭代更快、更安全，大幅降低整体交付逾期风险的同时，增加与非技术部门的协同可能性。

To 预算 & Buisness

纯软件层面的高效发布策略工具，减少开发团队对DevOps能力与硬件资源的依赖，减少硬件预算开支。按Feature的完成节奏，无需排期规划，老板说上线就上线。赋予企业实验性开发的能力，赋予企业关键迭代的能力

Feature flags的价值

Feature flags拥有缓解发布压力，降低发布风险，提高交付质量，提前试错时间，加快反馈速度的价值

开发者反馈角度

Sleuth.io与Launchdarkly对数千名使用Feature flags专家工程师做了调研，哪些是工程师们使用Feature flags的主要价值。（PS：小编也与超过50个使用Feature flags的工程师进行了沟通，与这份调研结果基本一致）

根据统计，工程师们使用Feature flags的原因如下（按统计排名从高到低，只取图中前7点）：

• 降低发布风险
• 增加发布Feature的速度
• 实验性Feature开发
• 缓解发布压力
• 无需重部署也可以秒级对Feature做回滚
• 将新特性发生异常的损失降低至最小
• AB测试能力

研发效能DORA指标角度

从Feature flags独角兽Launchdarkly多年对超过2000家企业的数据统计，以权威的谷歌DORA指标衡量，发现Feature flags可以使团队拥有非常出色的研发效能：

• Lead Time，60%+减少代码推送到交付的时间
• Change fail rate，70%+减少变更失败率
• MTTR，30%+减少从事故发生到修复的时间
• Deployment Frequency，9倍提高部署上线频率

关于上述指标的具体内容，以及Feature flags如何提高其性能，可以参照下方引用链接的文章

Feature flags大幅度提升DevOps性能，助力成为顶级研发团队

应用场景

小编会持续的丰富应用场景，以及尽量在不同的场景中给出更多的描述、代码示例等等。

Feature的渐进式发布（金丝雀、灰度）

通过使用If/else或更复杂的决策树的Feature flag声明包裹功能特性 (Feature) 代码后，可以通过控制Feature flag的返回值实现对一个功能特性 (Feature) 的渐进式发布（金丝雀、灰度）。

if(flags.newFeatureA == "v1.0.2") {         
    runFeatureAV2(); 
}

我们可以通过后台配置发布策略，如：

1. 将新的版本发给测试组或一个分组
2. 将新的版本先发给10%的粘性用户
3. 针对出现BUG的客户和Feature，独立回滚版本

生产环境中测试Feature，缓解发布压力

在一连串的复杂的、精细的、多步骤的测试后(单元测试, 整体测试，性能测试, 安全测试，Acceptance Test)，正式上线至生产环境后仍然会有可能出现BUG。更何况在很多企业、很多场景中，正式上线前的测试覆盖率并不高。所以，就很有必要提出一种在真实生产环境中测试的方案，来缓解发布的压力，在交付给最终客户时有一个更好的保障。使用Beta环境、蓝绿发布、灰度发布的多重组合是一种解决方案：

1. 程序运行在一个独立环境，数据和客户都在真实的生产环境
2. 根据染色流量逐步的推向给用户，至100%无问题后进行切换

相对传统的Beta、灰度环境，Feature flag拥有以下特点和优势：

1. 100%的生产环境，包括数据、用户、服务器、网络资源等。
2. 在发布至公众前，基于Feature独立测试，大幅减少延期可能。
3. 无需重新部署，可以秒级直接回滚Feature版本。
4. 不因一个Feature的问题影响整体的发布节奏。

综上，大大的缓解了工程师发布压力，尤其是缓解了因快交付节奏影响的质量问题和造成的巨大心理压力。

数据与云移植

我们希望的系统移植一定是平滑的、客户无感知的、不出意外的、不宕机的。那么我们可以用Feature flags解决这个问题。

一个简单的数据处理架构变更的移植场景

为了处理更大的吞吐量，我们开发了个新的数据处理系统，将一个Web APP的数据存储处理从API内部执行转为了通过Amazon Kinesis连接至Lambda服务进行数据处理与存储。

1. 生产环境内部测试新的数据处理方式，如果有问题修改BUG重新部署。
2. 分配20%的流量使用新的数据处理方式。若某环节出现性能瓶颈时，回退到旧版处理方式。按此方式一次分流至新版本，直至100%。

数据库迁移场景

我们有可能会做大的数据库变更，如从sql数据存储方式转移至nosql数据存储，从MySql移植到TiDB，或者是从一个旧结构表格移植到新结构表格等等。

使用Feature flags，我们可以在新旧两个数据库（或数据表）之间进行选择性平滑迁移。下图展示了一个数据库间移植的全过程，先将写操作平滑移植后，再做读操作的平滑移植。这个Traffic的分配，可以是按照Feature模块、客户公司等逐步的测试、逐步的开放。除了整个数据库移植外，也可以略加调整实现数据表（或数据文档库）的移植。

比如在下面的移植过程中，有一个读写性能的问题（就是同一个程序同时读写两个数据库）。而敏捷开关提供的Feature flags除了控制分流外，也会致力于相关的性能优化与框架语法使用优化。

实验性开发（Experimental Development）

即有计划的、有预谋的实验性的开发、发布某一个功能特性，以最小的成本去试错一个功能特性的用户接受程度。往往这些功能在对外开放时，是不完善的，甚至是有BUG的。这种实验性功能会有针对性的推向不同的客户。而企业对这类功能的期望则是尽可能获得更多的真实反馈，从而决定是否持续在这个功能上进行投入。这是一个在领先的企业中常见的立即试错、立即反馈的做法。而这种做法，往往可以起到出奇制胜的效果。（下图是Docker对外开放的一个实验性功能的截图）

使用Feature flags管理客户订阅计划

在软件中，订阅权限可以对个人或组织如何使用软件提供精细的控制。例如，软件即服务(SaaS)解决方案通常提供不同的会员计划。权限定义了每个计划可以访问的功能。权限有时被称为 "付费墙"，因为功能只对付费用户开放。管理订阅权限是一个耗时的、持续变化的工作：· 当新功能发布时，你需要决定哪些客户和订阅计划可以使用它· 随着竞争格局的变化，原来只对较高层次开发的订阅计划可能会对所有人开放· 销售团队想做一个限时促销，向低层计划提供该功能，以吸引他们升级· 客户成功部门想把某些功能提供给最近受到事件影响的客户，以示善意

在Feature Management平台的背景下，Feature flags可以简化管理订阅权限的过程。从而带来更好的客户体验和更高的运营效率。与其为一个要求特定功能的客户创建一个定制的构建，不如在该功能上加上一个Flag，并将其发布给该特定客户。这样可以为客户释放额外的价值，减少管理技术债务，将风险降到最低。使用敏捷开关，可以更好地管理订阅，如：

• 给不同的员工赋予Feature flag不同的管理权限，指定可授权的客户级别与订阅计划。
• 通过日志记录分析客户的付费意愿，并可以定位错误的权限变更及进行快速处理。
• 通过Webhook，API等方式，与系统的其他相关模块关联，实现自动化的订阅权限切换。
• 为某个临时权限设置预开启时间与结束时间，减少员工的时间管理方面的工作负担。

多版本管理与持续交付

很多产品面临着不同的客户需要定制不同服务，如MFA的技术方式不同，网络资源部署架构不同，数据的介入与导出的结构不同等等情况。各个模块的小版本不同，导致原本一个代码库从一个主分支，会慢慢地出现多个长周期的Branch，且每个Branch都不能被删除。每次代码版本的更新可能都需要与这些分支重新的合并、测试。造成随着系统的持续增长，代码管理的难度越来越大、“老赖”长分支越来越多。

而使用敏捷开关，可以在一定程度上缓解压力。敏捷开关通过If/Else或更复杂的决策树声明，使同一特性针对不同客户的不同版本的代码，存留在同一个代码仓库与分支中。在针对不同的客户进行部署、发布时，只需要通过根据客户画像进行Feature flag配置，即可快速交付一套符合客户画像的软件产品。敏捷开关也在为此提供更好的版本管理可视化工具，辅助操作。

基于Feature的链路灰度

目前，如Java的Dubbo, Spring Cloud，Istio都有类似的服务，这些方法都是通过一个微服务网格服务去实现的。而敏捷开关提供的Feature Management管理平台，通过纯软件维度实现类似的效果。Feature Management平台加持的链路灰度，并不是基于大版本，而是基于Feature的。与微服务的链路灰度相比，具有如下的特质：

Feature flag不一定适合所有的链路灰度场景。在微服务架构的全链路灰度，Feature flag也可以起到不一样的效果。敏捷开关在这方面也提供了更加灵活的支持。

基于主干开发

被Feature flags包裹的Feature branch直接与主干分支(main或trunk)合并。Feature branch的功能模块的发布受Feature flag控制，即使随着其他代码共同部署上线，在正式被发布前，也不会影响其他特性的正常使用。使基于主干开发的优势发挥至最大化，即短周期分支合并 (Short - lived branches)，从而实现：

1. 减少合并代码冲突，降低Code review难度。
2. 可立刻部署上线。做到立刻试错、反馈。
3. 只需测试主分支，大大减少QA测试压力。

在Feature Branch中使用Feature Flags

Feature branch，即开发人员针对某一个Feature单独开一个Git branch。让某个Feature的相关开发都基于此Branch进行。这样做，可以将开发更精细，避免一个不明确分支的长期生命周期，给后期的代码合并、产品质量带来时间与安全隐患。 我们通常是基于一个主分支（Main、Dev或Release）建立Feature branch。而这个Feature branch在完成后，合并到原主分支中。

在Feature branch合并到主分支(dev/main等)后，可以在任何一个节点进行部署、发布。看似美好的代码管理架构，在实际工作中仍然会出很多问题。 产生问题的原因是，Feature的发布与部署被紧紧扣住。

使用vs不使用Feature flag

使用Feature flags，让Feature的部署与发布解耦。使Feature对应的代码可以不通过Git操作，不重新部署实现回滚。以本场景的第一张图为例，下面的图标描述了在Feature branching中使用Feature flags的好处：

AB测试

可以简单理解为AB测试，是关键迭代的必备工具。即通过为同一个功能提供两种版本。在发布后，根据用户的使用情况确定哪一种版本更好用，从而决定下一步的开发或商业计划。

上面是如何使用feature flags实现AB测试，当然也需要有配套的s数据收集与统计分析功能，才可以真正的实现可靠有用的AB测试。

跨组织协同

有时组织中的不同团队可能用这不同的任务协同管理工具，或在同一个工具中的不同项目组。此时可以使用Feature Management平台中的插件安装在不同的协同工具中，使同一个Feature可以同时被多个任务管理工具查看、分享和控制。受到Feature flags的权限管理控制，并不会造成团队乱用Feature flags的现象。图示可以参照Feature Management平台章节中左图

远程配置

此时的Feature Flags SDK将作为一个配置文件接收器和分发器使用。我们只需要在Feature Management平台上配置对应Feature flag的返回值，设置返回值的格式和内容即可。Feature flags SDK通常可以支持如Http请求、gRPC、websocket等单向、双向、长链接的通信方式，使后台的配置更新可以主动或被动的推送到程序运行端。并且Feature flags收到配置后，工程师可以高性能、线程安全、架构友好的方式去获得最新被下发的配置信息。

使用Feature flags工具实现配置下发可以满足很多通用情况。由Feature Management平台加持的Feature flags可以更好的在团队协同、权限管理、定时设置、批阅审核、合规等方面控制配置下发的安全性、高效性。

Feature Management平台

Feature flags是个相对不年轻的概念和技术，但是Feature Management确是近几年最火的概念之一。

Feature management gives you peace of mind and control over your software, so you can boost developer productivity, improve morale, and accelerate innovation.

Feature Management本质是更好的去管理Feature flags和其控制的Feature。而对Feature的管理人从开发人员延伸至整个团队、企业。一个好的Feature Management平台，是赋予全团队管理Feature的能力。用当今流行的话说，Feature management平台可以大幅度的降低跨组织协同成本，降低跨组织沟通难度。并且让企业的开发与业务增长更紧密的契合。如下左图所示，所有的部门通过一个开关紧密相连。如下右图所示，在同一时间内，产品从多次内部迭代变为了多次市场真实的反馈迭代，让企业有能力做到立即试错、立即反馈。

自研 & 敏捷开关

为什么要选择我们？ 核心的两个优势：

1. 9倍提高交付速度，实现老板说上线就可以上线，我们现有客户的平均迭代速度提高了3倍以上。

2. 用更友好、更安全的用户体验、赋予非技术团队交付与控制元宇宙资源的能力

总结

Feature flags在近几年开始流行，绝对不是巧合，而是因为他真的可以给软件工程带来前所未有的进化甚至革新。Atlassian公司说“Feature flags是敏捷开发武器库中的一个有力补充”。

Feature flags 是企业提高研发效能，提高GTM成功率的必备技术元素。