面向快速迭代，如何降低上线风险？字节跳动 DataTester 团队找到风险与迭代的平衡点——渐进式发布。
渐进式发布(Progressive Delivery)被认为是持续发布（Continous Delivery）的下一代形态，其专注于增强发布过程控制与降低发布风险，最终提高整体收益。国际科技巨头比如 Amazon、Google 和 Netflix 等公司每天通过渐进式发布的方式将数千次的功能更新、bug 修复等更新到用户环境。
快速迭代的同时，避免不了引入一些预期之外的 bug。因此需要如何采用合适的工具，在风险与收益之间找到一个很好的平衡点就显得尤为重要。目前持续发布（CD）能够通过一些用户数据、系统监控或者一些核心指标对部署的功能进行监控，当发现问题及时回滚，以此形成一个持续迭代闭环。但是当用户体量非常大的时候，一个小的问题可能会造成难以衡量的损失，这是不可接受的。
为了找到风险与迭代的平衡点，渐进式发布的方式渐渐被提出并且深受重视。
什么是渐进式发布
渐进式发布有两个特点：发布进度控制和发布阶段授权。
其中发布进度控制即按一定的节奏将新的软件或者功能向用户推送，发布节奏可以是连续的也可以是分步骤的，以此控制每次生效的范围。这种做法建立在持续交付的核心原则之上，即将“代码部署”与“功能发布”分开。
发布阶段授权是指在不同的阶段将功能的操作权限授权给不同的团队，比如将功能的所有权慢慢从工程转移到产品，然后从产品管理转移到营销等等。
![]()
![]()
发布进度控制和发布阶段授权并用，降低了持续交付相关的风险，并赋予团队在整个发布周期中更多的控制权。
持续发布与渐进式发布区别
持续集成与持续发布（CI/CD）中强调主干分支的代码需要时刻保持在可部署的状态，这需要不断地将 feature 开发分支与主干分支进行合并，而不是等待一周甚至几周的时间，待所有功能开发完并通过完整的测试再合并到主干分支。CI/CD 的目的就是为了加快软件的开发与部署速度与效率，将新的功能尽快部署上线，同时尽可能降低风险。
虽然 CI/CD 能够加速软件与功能的交付速度，但是与之而来的风险并没有很好消除。当所有功能一次上线到生产环境后，如果包含比较严重的 bug 但不能及时发现，结果将很难预料。虽然 CI/CD 模型中的金丝雀发布（canary release）能够控制 bug 影响的范围，但是需要依赖比较复杂的控制系统。因此目前大部分场景下的 CI/CD 系统并不是严格意义上的持续集成与持续交付，大部分情况还是基于 feature 分支进行开发，然后在合适的时机合并到主干分支一并进行上线。
而渐进式发布的方式将新的功能隐藏在一个 feature flag 中，并可以通过可视化界面对发布的过程进行灵活控制，这是渐进式发布与目前 CI/CD 形态的一个比较关键的区别，其示意图。此外还有一键关闭、紧急生效参数、流量控制与监控等功能，当出现问题时不需要重新部署代码，通过按键即可进行功能的回滚，进而尽可能减少故障时的影响范围。可以说渐进式发布就是为解决发布问题、提高发布稳定性而生的发布理念。
![]()
![]()
那么渐进式发布有那么多的优点，想要独立开发一套控制系统又非常复杂，有没有简单易用的平台可以使用呢？答案是肯定的，火山引擎 A/B 测试中 FeatureFlag 智能发布专注于打磨发布平台，并实现与 A/B 测试的全方位联动，将是一个不错的选择。
FeatureFlag 智能发布平台是什么
Feature Flag 即 Feature Toggle，顾名思义其本质是一个隐藏在业务代码里面的一个控制逻辑。虽然看似简单的 if else 逻辑，但在发布领域有着非常强大的功能，可以实现生产环境中功能的动态控制而不需要要重新部署代码；此外还能够实现对生效流量、目标受众的灵活控制。
火山引擎A/B测试FeatureFlag功能基于先进的智能发布引擎和一站式配置托管平台，满足业务灰度发版、A/B 测试、定向差异化发布等不同应用场景。帮助开发、产品、运维人员在低风险环境下迭代新 Feature、修复 bug，实现精益敏捷开发。其核心目标在于保障应用迭代质量、助力精益开发效率、支持精细化业务场景与产品矩阵赋能。
![]()
![]()
如何基于 FeatureFlag 实现渐进式发布
一个好的平台想要做到易用一定要在功能复杂性与交互简洁性之间寻找平衡点。因此为了降低使用门槛，目前 Feature Flag 功能的配置只需要四步即可完成所需参数的配置，下面将对配置过程简要介绍。
01 - 基本信息配置
![]()
基本信息中的必须参数有 Feature 名称、Feature 对应的 key（也即某个功能对应的开关）和端类型。其中服务端与客户端只有在集成的时候稍有差别，但是在平台上使用的时候操作一致。所以只需要简单填写几个必须参数，第一步就完成了。
![]()
何为变体呢？其实可以简单理解 Feature Key 用于标识功能，而变体的值即为 Feature Key 对应的值，对应到代码里面这个值就是控制 if else 逻辑的数据。目前 Feature Flag 支持四种类型的参数配置，可以按需使用。
![]()
发布受众顾名思义用来控制当前配置的生效范围，其分为三个部****分。受众白名单即为优先级最高的受众条件，如果为某个用户开通了白名单，那么该用户会优先生效变体对应的值。自定义受众规则则可以灵活根据用户属性进行目标受众的圈选，这些参数和用户上报的属性相关，比如截图中即为渠道为 app store 且浏览器为 chrome 的用户会生效变体 2。均不符合以上条件的用户则会生效默认最终规则变体 1。
![]()
目前如果开通了 APM Insight 功能，那么是可以在监控指标这里选择一些预定义的性能指标作为监控，可以根据发布状态实时监控当前线上用户的情况，出现问题可以及时回滚。比如下图即为 JS 错误率的监控和聚合后的报警事件结果。
![]()
02 - 发布进度控制
为了实现渐进式发布中对发布进度的灵活控制，目前支持了手动发布、定时发布、自动下线、一键关闭、定向发布与随机发布等功能。现分别介绍如下。
手动增量发布
用户可以手动对当前的发布流量进行调节，进而实现对发布范围的控制。
![]()
适用场景
- 新功能上线，需要谨慎控制生效范围与效果
- 功能的发布节奏无法通过时间控制
定时自动发布
定时自动发布中可以提前按时间线设置流量的生效情况，到时间后将会自动生效对特定流量范围的用户生效。
![]()
适用场景
一键关闭
Feature Flag 能够帮助用户在生产环境测试新的 feature 效果，并可以通过开关快速的控制新 feature 的状态，以最大化的降低因新 feature 出现问题对线上环境的影响。传统情况下，上线新功能后发现问题的修改往往需要对代码的修改与服务的重新部署，进而会导致服务在一段时间内不可用，而这个过程往往比开关的控制更为复杂。该技术的背后是使用不同的逻辑分支，当 Feature Flag 开启的时候开启某些功能，反之关闭某些功能。
例如某个界面对一个看板进行了优化，那么可以通过配置 feature key 的方式，让一部分用户先体验新的看板功能，另一部分用户维持原样，这样一来可以根据线上效果判断这个功能对系统稳定性带来影响，也可以避免新看板存在的 bug 影响到整体的用户。在代码中你可能需要提前使用如下的代码：
if (isFeatureEnabled(‘new_dashboard’)) { // true or false showNewDashboard(); } else { showExistingDashboard(); }
![]()
定向发布
定向发布即只对指定用户生效特定新功能。Feature flag 可以通过用户分群或自动以目标受众的方式，控制新功能只对小范围用户生效。
例如，新上线的看板只对开通渠道为 app store 的用户生效。其代码如下：
if (isFeatureEnabled(‘channel’， ’app store‘)) { // true or false showNewDashboard();
} else { showExistingDashboard();
}
![]()
适用场景
- 比如某些用户已经是老粉了，而且倾向于尽早体验到产品的新功能，那么可以据此创建内测用户分群，新功能优先向这些用户推送。内测用户往往能够尽早为新功能提供反馈，进而及时做出功能调整。
- 国际化公司，在不同国家上线功能，可以通过国家圈选不同用户，进而为不同区域定制功能开发。
- 新的功能可以使用免费用户进行测试，查看功能的效果。
随机发布
随机发布即从线上所有用户抽取一部分流量做验证，如下图所示。
![]()
适用场景
- 新功能逐步上线，较指定日期全量上线，大大减小风险，即使出问题也只会影响一小部分用户，能够及时回滚。
- 风险较大的变更上线（例如基础设施迁移，数据迁移，大型重构或基础架构更改），基本不会对您的产品或业务产生负面影响。
- 提早暴露性能等问题，通过一部分流量的数据可以预测未来服务性能的变化，而不至于新功能的上线导致服务不可用。
03 - 发布阶段授权
发布阶段性授权是渐进式发布的另一个特点，那么 FeatureFlag 中同样也是支持的。具体的发布阶段授权主要包括两部分：权限管理和工作流程管理。
权限管理
结合账号体系，可以对每个 feature 按角色和用户设置权限。如果一个 feature 还在测试早期那么可以只为角色为研发的用户开通权限，以此类推。慢慢的将权限的控制移交给售前或者运营，实现功能上线与生效的分离。
![]()
工作流程管理
工作流程管理可以对发布过程进行控制，在不同的发布阶段可以引入不同的角色或者用户进行审核，灵活调整每个发布阶段的授权范围，确保发布过程的可控性。
![]()
FeatureFlag 智能发布有哪些应用场景
FeatureFlag 的应用场景非常多，基于其提供的渐进式发布能力，可以加速产品迭代过程，提升服务稳定性。下面从几个方面介绍下常见的应用场景。
01 - 新功能灰度发布
新功能发版可逐步灰度扩量，先让小部分用户体验新功能，观察用户反馈和数据表现，再初步扩量，潜藏问题及时发现快速止损，如下图所示。
- Step1 白名单测试+内测+众测
新功能上线前，先用白名单测试，并让内部用户和外部众测用户参与验证运行一段时间保证稳定性。
- Step2 发布审核内测通过后，邀请组内其他人参与 Review，通过后再进行后续的灰度。
- Step3 流量灰度+增量发布
优先选择 1%小流量，没问题逐步调整流量比例，灰度放量。在小流量过程发现了问题，我们及时回滚了配置，让旧版本配置生效。修复后再逐步放量新版本。
![]()
![]()
02 - FeatureFlag 与 A/B 测试打通
与 A/B 测试打通是火山引擎 FeatureFlag 功能的一大特色，两者的珠联璧合将会大大加快产品的迭代速度与效率。具体场景可分为以下三个部分：
- A/B 实验产生优胜版本后，可直接将实验固化为 feature，实现 A/B 实验的快速全量，并可采用灰度发布更加稳健全量。
- 在 FeatureFlag 智能发布创建 feature 后，可直接由 feature 开启 A/B 实验，快捷实现实验的开启和后续的管理。
- A/B 实验的参数可固化为 feature，放在 FeatureFlag 智能发布统一管理，产品可全局查看 feature 版本与实验的关系。
那么 A/B 测试与 FeatureFlag 两者间可以相互转化，他们之间的关系是怎么样的以及使用场景应该如何抉择？
![]()
A/B 测试是效果测试（一般用来验证某个想法是否符合预期），同一时间有多个版本功能对外提供服务，这些功能都是经过足够测试，达到了上线标准的服务，有差异但是没有新旧之分。它关注的是不同版本功能的实际效果，比如说转化率、留存等。其目的是为了验证产品的迭代方向是否正确。
Feature Flag 强调的是发布策略，目标是确保新上线的系统稳定，关注的是新系统的 BUG、性能隐患及稳定性，强调在发布过程中能够较早发现问题的存在。
Feature Flag 与 A/B 测试的抉择流程可以参考下图。
![]()
03 - 异常监控智能告警
目前 FeatureFlag 智能发布已经和 APM 应用性能监控打通，可实现从应用—>Feature—>Flag 级别的监控 。当某个监听的技术指标出现异常时自动触发报警，快速发现线上异常问题。后续对服务端技术指标的支持。
- 指标灵活组合，让监控更加便捷。
- 报警事件聚合，让监控更加完善
- 有效性验证+ACK，让监控更有效。
![]()
04 - 千人千面-人群差异化发布
基于 FeatureFlag 中灵活的自定义目标受众条件，可以实现不同用户下发不同的配置参数，真正实现千人千面，灵活发布。
- 可以根据不同人群特点展示功能，比如安卓用户推荐 QQ 登录，IOS 用户推荐微信登录，提升不同人群的个性化体验。
- 运营活动时，可针对不同地域、人群采用差异化的运营策略，实现细分人群的精细化运营。
- 自定义目标受众参数，满足业务定制化的定向发布需求。
![]()
05 - 增强持续集成与持续部署能力
CI/CD 使得开发者可以快速开发、迭代与发布新功能。持续部署(符合企业软件实践，它是完善持续集成原则的自然演化。但持续集成与部署案例却非常罕见，其中原因可能是需要复杂的管理以及担心部署失败而影响系统的可用性。
目前在开发过程中，开发者会从 develop 分支 checkout 新的分支出去开发自己的新功能，在充分测试完成后再合并到主干分支，这样主干分支能够保证在任意时刻都是可以上线的状态。但是这种开发方式存在一些问题，比如分支分出去时间越长往往代码合并难度越大。一旦代码库中存在了分支，也就不再是真正的持续集成了。当然你可以给每个分支建立一个对应的 CI，但它只能测试当前分支的正确性。如果在一个分支中修改了函数功能，但是在另一个分支还是按照原来的假设在使用，在合并的时候会引入 bug，需要大量的时间来修复这些 bug。
而基于 Feature Flag 的 CI 过程则如下图所示。开发完成的代码可以在任意时刻合到主干分支中，并通过 Feature Flag 开关控制未开发完成的功能对用户不可见；新的特性可以提前上线，产品或者运营等角色可通过开关控制何时与什么范围生效新的 Feature；对线上问题的修复，可以通过控制发布范围，使用线上流量进行验证。
- 进一步加快 CI/CD 进程，主干分支随时可以部署，提高迭代效率。
- 功能上线与代码部署的分离，通过 flag 将新功能隐藏，一方面方便线上小流量测试，另一方面产品或者运营可以按需开启功能，不需要再问研发要排期，提高协作效率。
![]()
总结
持续发布在现代软件公司的发展过程中发挥了比较重要的作用，但是持续发布时不增加必要的控制是非常危险的。渐进式发布方式在整个发布过程中加入了足够的控制，并且融合了发布阶段授权，可以大大降低持续部署时可能导致的问题。
FeatureFlag 智能发布能够更加方便帮助用户实现渐进式发布，并减少产品迭代过程中引入的问题和上线风险，最终在降低风险的前提下提高迭代速度。快速迭代、保证安全和实时控制，这就是火山引擎 A/B 测试的 FeatureFlag 智能发布功能。
**功能体验传送门：[火山引擎FeatureFlag]
**了解更多请戳：[火山引擎Feature智能发布帮助中心]
火山引擎 A/B 测试
A/B 测试，摆脱猜测，用科学的实验衡量决策收益，打造更好的产品，让业务的每一步都通往增长。
当前，火山引擎首度发布增长助推「火种计划」，火山引擎 A/B 测试作为「火种计划」产品之一，将为您免费提 2 亿事件量和 5 万 MAU，以及高达 12 个月的使用权。[体验传送门]
欢迎关注**“字节跳动数据平台”**同名公众号
