Bullet Train：在 CI 中使用特性标志和远程配置

由 Mux 赞助的 DEV 全球展示挑战赛：展示你的项目！

我问过很多开发者朋友，感觉持续集成 (CI) 和持续交付 (CD) 是大家要么已经在使用，要么很想使用的两种实践。开发者普遍都喜欢发布新功能，这是工作中令人满足的一部分。理想情况下，我们可以不断发布新功能，但随着项目复杂性和用户数量的增长，这种仓促地将代码推送到主分支的做法风险太大了。

这篇文章解释了我使用功能标志时发现的情况，以及 Solid State Group 最终开源https://bullet-train.io 的原因。

减少释放周期和压力

之前我参与过一些发布周期长达数月的项目，发现采用这种方法能让我轻松很多。此前，我发现以下情况：

• 用户验收测试 (UAT) 包括对多个相互关联的未发布功能进行广泛的测试。
• 迫在眉睫的紧急修复程序必须合并，这些程序已经应用到生产代码中，可能会与停滞的代码发生冲突/产生副作用。
• 由于事情太多，很难追踪到底有哪些内容会被发布。
• 一些看似次要的功能却耗时过长才发布，搁置数周却毫无价值。
• 发布的影响往往相当严重，一次性发布多个版本可能会导致应用程序崩溃，严重情况下甚至需要回滚。

简而言之，大型发行成本高昂且流程复杂。而分阶段发行通常可以减少包袱，讽刺的是，还能降低风险。

什么是“功能标志”？

令我惊讶的是，虽然我交谈过的人都对这些做法持非常积极的态度，但只有大约一半的人听说过功能开关。这意味着功能可以部署在生产环境中，但只有在需要时才会启用。

功能标志是一种通过配置来关闭应用程序某些功能的技术，无需部署新代码。
如果您采用持续集成/持续交付 (CI/CD) 并频繁发布版本，那么功能标志就非常重要。

为什么“功能标志”很重要

对我而言，能够在代码库之外控制功能，甚至在生产环境中为内部用户启用这些功能，完美契合了我的实践需求。
市面上有一些功能开关服务，它们都宣称具有以下几个优点：

• 将代码发布与功能部署分开。
• 引入了在生产环境中测试代码并逐步/有针对性地推出的功能
• 赋予非技术团队成员管理功能发布的能力
• 允许尽早测试功能，并针对未停滞的代码进行测试。
• 允许您推出测试版计划，以便尽早获得用户反馈。
• 能够远程关闭功能，从而减少了回滚代码的需要。

功能标志的不足之处

无需构建即可启用或禁用某些功能固然很好，但有些功能并非如此简单。这时远程配置就派上了用场。
我们经常需要配置某些功能属性，例如更新一些文本以推广应用内货币销售。之前，我曾使用 Firebase 的远程配置功能来配置移动应用，这通常意味着我们可以避免等待 iOS 和 Android 版本协同构建两天甚至更长时间。

隆重推出子弹头列车

鉴于我们发现使用功能开关和远程配置都带来了显著优势，我们决定构建自己的内部产品。这意味着我们可以利用现有的网站/移动应用，采用更一致、更规范的方法来开展我们已有的工作。

我们找不到任何能结合我们之前使用的两种方法的系统。像 LaunchDarkly 这样比较接近的产品价格远远超出我们的预算，而且也无法真正满足我们的需求。

该平台完全开源，并包含 JavaScript、React Native、NodeJS 和 Java SDK，因此您可以根据需要自行托管所有内容。我们还托管了一个 API 和管理前端，供大家试用。我们甚至用它来开发了 Bullet Train！欢迎您通过bullettrain@solidstategroup.com
向我们提供网站反馈。

祝您开发愉快！