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

一、背景

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

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

二、量化数据

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

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

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

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

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

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

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

版本报告

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

质量

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

时效

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

• Android

• iOS

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