What Is Feature Flag and What Problem Does It Solve?

什么是 Feature Flag 以及它解决什么问题？

@ 技术讨论

前言

Feature Flag 功能开关 = 开关用于管理程序中的功能

还记得之前参与某个项目使用 Git Flow 的方式管理产品发布，整个团队尽力好几个月打造某项功能，但随着时间过去它与持续进行中的主支线差距越来越大，最终也要花不少力气同步两个进度，也是在那次问题之后我更认可 Trunk Based Development🔗 流程的概念，其中提到 Feature Flag 是一种很好的技巧用来降低推送功能的风险与控制程度。

为什么需要 Feature Flag？

有一句话是说：「写程序和盖教堂一样，当完成之后，我们就开始祈祷」。背后隐藏着开发者对程序部署的不安与恐惧。关于部署最简单的模式即是随时把最新进度部署上线，但这样非黑及白的模式也造就一些问题：

  • 同步更新进度：产品更新周期是两周，但需要建立一个需要三个月才能完成的功能。该如何使用确保每个人都在主线上工作而不会在发布时暴露一个半成品功能？
  • 部署灵活性：改动可能会严重影响用户……
    • 灾难管理：出事了怎么即时回溯修复？能不能渐进的推动功能？
    • 调配功能：不同时机（节庆）和用户（不同等级与种类的用户）有不同的功能需求，如何管理调配？
    • 即时反馈：新功能需要被实际用户测试才能得到最真实的反馈。

导入 Feature Flag 可以解决以上问题，通过拆分「部署」与「发布」改善体验。

Feature Flag 的实践

Feature Flag 可以是简单到是手动改动程序代码，或是一段简单的判断逻辑根据环境变量或是依赖外部状态与服务改变程序行为，重点是调配功能的状态要如何存储？

地点难度响应速度改动速度额外花费灵活性
代码中简单快慢无高
环境变量简单快慢无低
数据库麻烦慢快无高
现成服务简单慢快付费高

Feature Flag 是一个简单易懂的概念，但在企业级规模上管理起来却颇为困难🔗，和许多最佳实践🔗可以探讨。

总结

开发人员应该自然的十分熟悉 Feature Flag 的概念，因为如今常见的版本控制策略都有提倡 Feature Branch 的概念，只是 Feature Flag 根据现有痛点探讨如何更好的改善发布的体验。随着项目规模扩大，这一项迟早会需要被探讨的问题解方。

可以从现成的服务了解这项策略的成熟形态：

延伸阅读