Feature Flag功能发布控制

　　Feature Flag允许关闭未完成的功能，你可以在主干上进行迭代开发，新功能即便未开发完成也不会影响发布，因为它对用户是关闭的。当功能开发完成之后，修改配置便可以让功能发布。这种操作甚至可以在线上进行，例如代码已经发布但功能不可见，你可以修改配置让功能对特定的用户(线上测试、小流量或者全量发布等)可见。如果发现新功能存在问题，那么可以通过配置文件来迅速回滚，而必须重新分支上线。Feature Flag原理示意图如下：

各自的优缺点

选择合适的方案，而不拘泥于方式本身

并没有万能的方案，两种方式都有各自的优缺点。

Feature Branches

优点：

• 同时开发多个功能分支不会影响主干和线上代码
• 在分支上开发新功能时不用担心对其他在开发的功能的影响
• 现有很多持续集成系统支持分支的构建、测试、部署等

缺点也很明显，Martin Fowler的文章中已经做了全面的阐述：

• 分支分出去时间越长往往代码合并难度越大
• 在一个分支中修改了函数名字可能会引入大量编译错误。这点被称为语义冲突（semantic conflict）
• 为了减少语义冲突，会尽量少做重构。而重构是持续改进代码质量的手段。如果在开发的过程中持续不断的存在功能分支，就会阻碍代码质量的改进。
• 一旦代码库中存在了分支，也就不再是真正的持续集成了。当然你可以给每个分支建立一个对应的CI，但它只能测试当前分支的正确性。如果在一个分支中修改了函数功能，但是在另一个分支还是按照原来的假设在使用，在合并的时候会引入bug，需要大量的时间来修复这些bug。

Feature Toggle

优点：

• 避免了分支合并代码冲突的问题，因为是基于主干的开发
• 每次提交都在主干，迭代速度明显有优势
• 新功能的整个过程都持续集成

缺点:

• 未完成的功能可能会部署到线上，如果配置有误可能将未完成的功能开启。当然可以将界面层最后开发避免过早暴露。
• 主干上担心提交代码影响其他功能。

　　我们可以根据需要选择合适的方案。Feature Flag在避免分支合并加快迭代上有优势，另外Feature Flag除了主干开发上的支持，还有什么实用功能呢？下面来介绍。

Feature Flag种类与应用

一般Feature Flag可以分为两类，见下所示：

发布开关：

• 在发布代码时关掉未完成的功能
• 生存期短
• 功能稳定就马上删除
• 在整个开发过程中有预定义的值

业务开关：

• 实现A/B测试
• 针对特定人群发布功能尽早获得反馈
• 针对特定条件开启或者关闭功能。例如可以设置在指定时间点开启，这样新功能将按照设定自动上线下线，无需手动上线，适合专题等情况
• 能线上开启或者关闭,实现快速回滚

　　发布开关主要是为了隐藏未开发完成的功能，而业务开关则可以帮助我们快速满足某些需求。例如A/B测试，Feature Flag可以轻松控制展现哪个功能，提升A/B测试的可维护性。我们也可以通过配置里面的逻辑让新功能针对小部分人群甚至是特定地域的人群发布，尽早获取功能的反馈。甚至是可以在线上开启调试，只让新功能对调试人员可见。而这些都只需要配置文件和简单的标记来实现。

谁在用Feature Flag

功能看起来很酷，但是不是新东西？有谁在用呢，我可不不愿意承担风险

　　事实上Feature Flag已经在国外互联网公司中获得广泛的使用。例如FaceBook、Google等公司使用基于主干的开发模式来持续集成开发，Feature Flag是其中一个基础技术。下面这幅图展现了FaceBook开发模式转变历程,可以看到几年前facebook就开始使用Feature Toggle，使用了Feature Flag关闭主干上未开发完成的功能来保证快速迭代和高频率的发布。

　　国外主干开发中推荐这样一种方式：trunk作为开发主线，所有开发人员完成开发后向及时向主干提交代码，开发人员不允许在主干上拉取分支。在发布的时候由系统拉取分支发布，主干上的bug修复及时同步到发布分支。开发人员可以本地使用git等工具进行版本管理。如下图所示：

　　虽然基于主干的开发模式已经成为国外的主流，但分支开发并不是不该使用。使用分支不推荐的是让新功能代码在分支上长时间堆积，分支应当是生存周期短的。

　　实际应用中我们可以根据业务场景来选择是否用功能分支还是Feature Flag，并且这两者可以相互结合。例如在文章前面提到的示例中，可以使用分支来开发细分的子功能保持分支及时合并，同时使用Feature Flag来控制功能的发布，提升工作效率。