得物App灰度&全量发布效率提升实践

一、背景

得物的发布采用固定的双周迭代，在此基础上如有紧急的需求可以申请中间插入单周迭代版本，在以往的迭代发布过程中从开始准备灰度发布事宜到主要应用市场上架时间跨度较长，站在业务的角度像AB、埋点、新特性反馈的时间太长。

最近我们针对发布流程做了整个链路的优化，通过调整发布节奏、提升双端发布系统自动化能力等措施，帮助业务触达用户效率(每版本提前1天)，下文将详细讲述此过程。

二、量化数据

发布过程中涉及的不同职能的业务域较多，信息不透明、无法从全局视角了解整体发布情况，因此想要做优化首先需要量化发布数据，主要的作用包括如下：

1. 实时监控：帮助团队实时监控灰度发布的进度和效果。通过数据分析，可以了解不同版本在不同阶段的表现，及时发现并解决问题，确保发布过程顺利进行。

2. 效果评估：可以评估不同灰度发布策略的效果。比如可以根据数据分析结果调整灰度量、时间等参数，以提高发布效率和质量。

3. 问题诊断：帮助团队快速诊断和定位发布过程中出现的问题。通过数据分析，可以找出导致问题的原因，有针对性地进行修复和优化。

4. 持续优化：通过不断积累和分析发布数据，团队可以发现发布过程中的潜在改进空间，持续优化发布流程和策略。量化数据的作用在于指导团队进行持续改进，提升灰度发布效率和成功率。

综上所述，量化发布数据在灰度发布效率提升项目中扮演着至关重要的角色，可以帮助团队监控、评估、诊断和优化发布过程，从而实现更高效的灰度发布。

我们对灰度的理解是用时间来换取减少潜在问题造成的影响面，好的质量意味着较少的灰度时间，反之效率的提升也能为应对潜在的质量问题提供更多的时间buffer，因此量化数据围绕着“质量”、“效率”两个关键字展开，每个迭代记录各阶段细化到具体的业务域的关键时间点、异常事件等，以版本报告、季度报告的形式呈现出来。

版本报告

以质量和时效两个维度记录迭代发布过程中的重要时间点、异常事件，比如服务端各域发布时间、客户端各业务域代码集成时间、App构建时间、测试可开始回归/回归结束时间、灰度时间段/人数/质量情况、灰度因质量问题造成的熔断、应用市场开始上架/审核通过时间、应用市场拒审事件。

质量

灰度对用户产生的影响有弹窗、安装、崩溃，我们主要关注了后两个，分别使用灰度覆盖人数(此版本累计安装的设备数)、bug影响人数(累计崩溃的设备数)来衡量。

时效

业务迭代版本(首个小版本)是整个迭代发布任务中最复杂的，依赖于服务端发布完成、客户端所有业务组件集成完毕、QA完成全量的测试回归，因此需要重点关注，后续的版本主要关注上次灰度的问题修复时效，最终关注应用市场的上架情况(Android关注华为、小米、vivo、oppo四大应用市场)；服务端发布和客户端集成组件用固定的时间来衡量，QA测试回归有前置依赖使用可开始测试时间+固定的时长来衡量，上架使用App全量时间到应用市场审核通过来衡量。

• Android

• iOS

  区别于Android可以使用弹窗提示脱离应用市场进行灰度，iOS testflight灰度名额较少，主要依赖苹果审核通过后通过逐步放量来发现问题。

名词解释

• 灰度时间: Android: 在发布系统上操作开始灰度时间(老版本用户可展示升级弹窗提示的时间),iOS: AppStore审核通过后操作开始放量1%的时间。

• 提供测试包时间: 提供给测试用作回归功能的包出包时间。

• 测试可开始测试回归时间: MAX(服务端发布完成时间，客户端提供测试包时间)（QA依赖服务端功能发布完成和客户端提供灰度包）

季度报告

季度报告是对本季度版本报告数据的纵向整合，主要关注各个关键指标优劣化情况和各个团队在灰度发布中的表现情况。

灰度影响

安装

• 版本趋势

  每个迭代安装量分布、累计安装量

• 季度汇总&各团队表现情况

  季度总共发布了多少个灰度版本以及灰度覆盖人数，以及归因到每个业务域的数据，与上个季度相比的优劣化情况以及具体原因。

异常发布: 正常情况下，一灰发现问题，二灰验证修复情况，二灰和全量版本之间的版本视为异常发布。

• 灰度轮次安装量分布

  对比各轮次安装量情况，是否有异常偏高情况，另外体现异常发布导致的安装量。

崩溃

季度总共以及各业务域在灰度期间崩溃的设备数、与上个季度相比的优劣化情况以及具体原因：

一灰归属：公共轮次（计入公共）。

二灰归属：业务域所属问题累计崩溃设备数>=30%（如无必修则视为公共bugfix验证轮次，计入公共），其它灰度版本归属: 开版问题所属业务域。

• 版本趋势

  每个迭代Crash分布、累计Crash影响用户数。

• 各团队表现情况

  汇总这个季度内每个业务域所属问题在灰度期间所有崩溃的设备数，与上个季度相比的优劣化情况。

• 灰度轮次Crash对比

  对比各轮次Crash影响用户数分布情况，一灰后占比低说明一灰问题修复情况较好。

时效

• 各职能域累计影响时长对比

  体现服务端、客户端、测试累计影响时长分布情况。

服务端

• 版本趋势

  以固定时间发布完成为目标，整体延期趋势。

       不同业务域在每个版本的发布表现。

• 各团队表现情况

  对比不同域在这个季度累计的延期时长，以及相邻季度的优劣化情况。

客户端

• 提测延期版本趋势

  以固定时间完成出包提测为目标的版本延期趋势。

• 各团队表现情况

  业务域组件集成延期，对产生两种类型的影响，第一种: 尚未提测会导致App打包延期而导致提测延期，第二种: 如果测试提出的问题修复过晚，会影响到灰度。

测试回归

• 版本趋势

  以3h完成测试回归为目标整体完成情况，回归延期会产生客户端问题修复延期、灰度延期的风险。

• 各团队表现情况

全量版本发布

• 发布类型分布对比

• 版本趋势

  每个迭代发布全量版本数。

友商发布

横向对比各友商季度累计上架的版本数，分析友商发布情况以及得物App所处的位置。

• 季度对比

• 全年的对比

iOS AppStrore审核

• 版本趋势: 每个版本苹果审核花费的时长

三、优化方向

通过对一个季度的数据进行量化分析，识别出了各子任务的依赖关系和并行情况以及关键卡点，逐步揭示了灰度发布过程中的问题，并为后续优化提供了明确的指引，主要有如下几个方面：

• 各团队灰度节奏不一致:  服务端发布、客户端代码集成、测试回归等这些同类型的任务中，不同业务域节奏不一致。

  为同类型任务划定出一个明确的完成时间点，使同类型的任务尽可能的并行进行，例如为服务端发布完成和提供测试包时间约定一个相同的时间点完成，QA测试回归有前面两者的依赖约定好固定的完成时长，较大周期的任务时间点确认好了以后，在细化子任务的时间点，例如提供测试包需依赖客户端业务组件集成完成、App构建task完成，进而可以根据App构建所需时长反推出客户端代码集成需在某个时间点完成(等同于开始构建测试包时间)。

• 前后任务之间存在时间上的空白（任务前置依赖满足后任务开始时间滞后)

  • 提升工作流平台自动化能力，检测任务前置依赖完成情况自动化的触发

  • 需人工进行的任务在固定的时间点或者前置依赖完成后增加提醒功能

  • 提供事件订阅机制，可以让大家接收自己关注的事件通知，比如发布计划创建、App开始构建、某个应用市场上架等

• 质量问题发现滞后

  • 建立打包/灰度/全量前的卡口机制，线下环节或上次灰度中发现的问题在打包前必须标记已完成

  • 要求各域在首次灰度时打开需验证功能的开关

  • 像版本号这样的版本参数，在建发布计划时自动推断出来填充表单

四、调整发布节奏

通过分析历史发布数据发现不同域在发布节奏上有不一致的情况，通过与各职能业务线团队沟通，节奏上我们做了如下图所示的调整。调整后的时间线更加紧凑，服务端发布和客户端App打包时间提前了4个小时，首次灰度利用了夜间时间，使得灰度时间提前了14个小时。

五、双端提升发布系统自动化能力

在得物内部，我们有承载双端开发、发布和最终上架流程的工作流平台。通过提升平台的自动化能力和事件分发能力，显著地提高了灰度发布的效率。

自动创建发布计划

每个版本发布前需要提前创建发布计划，参数包括版本号、计划App打包时间、计划灰度时间。

• 自动推断版本参数: 防止手动填写错误，根据得物App版本号规则和上一次发布的版本参数，自动推断此版本的versionName、versionCode、buildNumber等参数。

• 首个版本自动创建发布计划: 首个版本的计划App打包时间、计划灰度时间是固定的，在合适的时间点自动化的创建出来可以防止版本owner忘记操作。

打包/灰度/全量前卡口

App打包前/灰度前/全量前都有相应的前置检查项，比如隐私合规、代码是否合入、线下包崩溃以及上次灰度的问题是否解决、包体积是否达标、三方组件审批情况等等。很多检查能力分散在各个子系统，依赖人工检查工作量较大且容易出错，因此提供了流程上的卡点能力。

App打包前置依赖提醒

组件集成和未解决的线下Crash，推送消息至问题负责人和大群的提醒。

• 线下Crash提醒

  测试环境的包出现崩溃时会有上报，我们的流程要求灰度发布前必须全部解决掉，在灰度前3天开始推送提醒，在灰度当天在大群中提醒。

• 组件集成提醒（业务组件集成、snapshot组件release）

自动打包

• 首个灰度版本前置依赖满足后自动打包:  首个灰度版本打包前置依赖任务和检查项较多。

• 计划发布时间打包:  到了预设的发布时间自动触发一次App构建。

• KOL渠道自动打包:  为了防止应用宝抓包造成渠道错乱，新版本一般是等待应用宝审核通过后，版本owner主动触发KOL渠道包的构建，监控应用宝上架自动触发。

测试回归催收

灰度包出包后客户端版本owner手动提交审批(版本号、包下载地址等)，然后把审批实例发送到灰度发布大群中。防止QA回归完成后忘记在系统上操作，做了快到计划回归完成时间时把尚未通过的QA自动拉到飞书群中，一方面可以提醒QA另外可以询问测试卡点。

事件订阅

整个发布过程中特定职能的人员、系统，会关心某些事件，例如打包成功、发布计划创建、提测等等。

工作流平台把很多外部会兴趣的消息封装成统一的事件对外部分发，支持在前端对某个事件配置飞书通知的接收人/群，外部系统也支持通过DMQ、HTTP两种协议来接收事件。

Android应用市场上架监控

以往想知道某个市场上架情况，只能使用相应品牌的手机去查看，自动化的上架监控能及时把上架消息通知给关注者。

iOS定制化苹果商店

定制化苹果商店基于 AppStoreConnectAPI 搭建一套商店系统。目的解决苹果商店操作权限管控力度过大、无操作记录、无进度通知、学习成本高、一次提审和发布需要操作多个系统等问题。系统包含应用管理、版本创建，支持版本预览图、审核信息、附件、提审包配置，支持版本提审、版本放量、版本审核进度监控。实现一站式、一键式、可跟踪的提审发布系统。

六、总结

如何把高质量的新版本及时的触达用户，得物App在这一方向上持续投入了大量精力，在各部门通力合作下延期时长下降了超过7成，全量发布最终实现了每版本平均提前一天的业务效率。

*文/tongyapeng

本文属得物技术原创，更多精彩文章请看：得物技术官网

未经得物技术许可严禁转载，否则依法追究法律责任！