Feature Flag功能发布控制

背景

　　产品在新功能发布前，可能会采取小流量测试的方式，或者在确定方案前使用A/B测试来衡量。一般开发人员会跟运维同学合作，通过一些现有平台切换机器或者流量来实现。本文介绍了另外一种简便的方式，并解释了其在持续集成上的应用，同时提供了现有的开发框架供快速使用。

Feature Flag VS Feature Branches

　　Feature Flag(又名 Feature Toggle、Flip等)是一种允许控制线上功能开启或者关闭的方式，通常会采取配置文件的方式来控制。提到Feature Flag一般都会跟Feature Branches进行比较。这两个有什么关联与差别呢？可以通过一个简单的示例来比较：

　　假设产品需要添加一个功能，如果你在主干上进行开发，那么通常的做法是在前端开发人员在界面上添加功能，然后可能会有其他同学来完成后端服务、安全保障，最后测试及Bug修复并发布上线。如下图所示：

　　上图中有个明显的问题是主干分支上在功能测试完毕之前是不能进行发布的，因为功能已经在提供在界面中，必须完备之后才能发布给用户使用。

　　当然解决方法也很简单，例如我们常见的是会使用功能分支(Feature Branches)来解决。在主干上拉取一个分支，然后在分支上开完测试完之后在合并到主干上，这样就不会影响主干的持续发布了。如果有另外的新的功能那么同样拉取新的分支来解决。如下图：

　　但这样同样存在问题，如果一个功能比较复杂，开发的周期较长，而在此期间主干上已经多次修改代码，那么等分支上开发完之后合并到主干将是一个比较麻烦的工作。你必须去处理各种冲突，与其他开发人员沟通修改点。这是很多人不愿意做的。

　　于是有人提供了新的方案来解决这个问题。例如将开发工作拆分成多个小块，在各个分支上开发测试完成后及时合并到主干中，并且可以先隐藏界面功能，直到所有的功能开发完成之后才展现。这样每次合并的难度就小多了；或者每次将主干上的修改都及时同步到分支上，这样分支上开发完成之后合并到主干上就简单多了。

　　但如果发布时出现bug怎么办？可能常见的是进行回滚重新上线。有什么方式既能避免分支合并的麻烦、保持主干快速迭代随时发布，又能更好的控制新功能的发布、方便的进行小流量或快速回滚操作呢？答案就是Feature Flag。