Feature branches与Feature flags 的对比

两者的区别

Feature branches更多的是一种分支管理的策略，就是每个feature都有一个独立的分支，完成开发后合并到主干分支，它并不关心这些feature如何部署、什么时候发布的问题。

而feature flags应该是一种按功能进行发布的机制，允许控制某个功能对特定群体开放。它需要你把feature实现成可以用逻辑判断的方式控制其是否上线。

Gitlab集成了unleash来支持feature flag，可以看看这个在线demo。使用方式大概就是在后台中配置feature flag，在项目中接入相应的SDK，然后就可以在业务代码中通过接口判断某个feature是否开启。

另一个例子是这篇文章中实现的feature flags，大致流程为

1. 设计feature flags配置文件

<?xml version="1.0" encoding="utf-8"?>
<!--
  In this group we should register Azure DevOps specific features and sets their states.
-->
<ServicingStepGroup name="AzureDevOpsFeatureAvailability" … >
  <Steps>
    <!-- Feature Availability -->
    <ServicingStep name="Register features" stepPerformer="FeatureAvailability" … >
      <StepData>
        <!--specifying owner to allow implicit removal of features -->
        <Features owner="AzureDevOps">
           <!-- Begin TFVC/Git -->
           <Feature name="SourceControl.Revert" description="Source control revert features" />

1. 运行时根据配置文件判断是否开启某个功能。
2. 提供管理平台来更新配置文件

两者的结合

两者是完全不同的概念，并且同时使用也不冲突

使用feature flags可以同时使用feature branches，这里引用这篇文章的一段话：

Feature flags can be used with feature branches. To create a feature flag, a developer creates a feature branch and commits the new feature flag code to the feature branch. Once instrumented, the feature branch is merged and deployed and the feature flag then becomes accessible on production.

或者其它分支策略：

Feature flags enable development teams to include incomplete features in main without affecting anybody else. As long as the codepath is isolated behind a feature flag, it's generally safe to build and publish that code without side effects impacting normal usage

思考

feature flags是否可以用于多环境测试？

是可以的。如果控制某个feature只对内部测试账号生效，测试完成对所有人生效。实际就等同于支持多Feature并行测试并且独立发布。

但弊端是：

1. 业务代码的开发方式需要改变。需要能够从逻辑上控制当前开发的Feature的显示隐藏
2. 存在风险点：能否在业务代码中正确控制feature的启动和关闭。例如开发某个feature的时候，可能会在页面上增加一个按钮，同时又修改了一些公共的代码。我们可以用逻辑判断控制按钮的显示隐藏，但是修改的公共代码就可能被遗漏，这部分代码就可能被发布到线上
3. 不同Feature可能存在交叉的代码，这种冲突难以解决

结合团队实际情况，最终方案：