用数据说话:即使提高发布频率,质量与产量也能兼得!

| 2021-12-18

所有工程师都在同一条主干分支上工作,每天数千次代码提交,他们的工作进度是否会互相影响,代码质量是否会很差呢?

在上一篇文章《 移动端的持续交付实践》中,我们描述了移动端(包括 Android 和 iOS )每周发布一次所用的分支模式与发布流程。

那么,与云服务应用的持续部署实践所获得的生产力和质量相比,这种移动应用的持续部署过程对开发效率和软件质量有何影响呢?

本文将用统计数据来说明这一问题。

软件工程团队的吞吐量与质量

软件工程效能度量是一个非常困难的事。在一个软件工程数据收集不全面的软件公司中,尤其如此。

然而,针对一个在 7 年时间里,工程人员规模从 15 人发展到 1500人,移动软件发布周期从 8 周缩短到 1 周的大型软件工程团队来说,当其具有比较全面的历史数据时,就具备了一定的研究价值。

因为,对同一个团队来说,只要主要工程模式变化不大,时间够长,数据够标准,多而全,即便没有太多的数据维度,也能说明一些问题。

本文分析所用的数据在时间跨度上是从 2009 年 1 月到 2016 年 5 月这段时间。它包括来自版本控制系统的所有提交日志、能收集到的App的所有崩溃、Facebook 员工和用户报告上来的所有问题,以及在发布过程中确定为关键问题的所有问题。

我们从「吞吐量」和「质量」两个方面来衡量它。

单个工程师的平均生产效率

在这里,我们选择两个指标来衡量工程师的平均生产效率,它们分别是:(1)每人每天修改或添加的代码行数;(2)每人每天提交的次数。

结论如下:

在 Facebook, Android 和 iOS 开发人员每天每人分别生产 70 行代码和 64.7 行代码。

代码行数的统计规则:

  1. 由自动化工具机器人提交的代码已剔除
  2. 一次提交超过 2000 行的代码已剔除,因为这一动作可能是引入第三方库代码,也可能是移动了代码目录等。
  3. 数据按月统计,按人天求平均。
  4. 每日人数计算:在每个统计日的前两周时间内有移动代码提交的人才能被计算在内。

2014年到2016年,Android 和 iOS 的开发人员每人每天提交0.7次和0.8次。

即使移动工程师团队的规模增长了15倍,人均生产效率并没有发生变化。

我们使用几下三个指标作为「软件产品质量」的代理指标,它们分别是:

  1. 生产环境中出现的代码缺陷数量与严重度
  2. 移动 App 在不同阶段的崩溃率
  3. 发布窗口期的 Cherry-pick 数量
  4. 发布窗口期的 Launch-blocker 数量

研究结果还表明,尽管移动软件开发团队规模增长移动产品逻辑变得复杂发布周期变短,移动 App 的产品质量并没有恶化

事实上,某些指标显示,质量有所提高。

生产环境中的代码缺陷数量与严重度

以下是从 2011 年 3 月至 2016 年 5 月之间的统计数据。

从图中可以看出,

从 2012 到 2016 年,对于每次生产环境发布,「 Critical 」的 bug 数量基本上是 0 或者 1,原因可能在于:

  • 特别严重的 bug 在测试时就被发现了;
  • 公司对特别严重 bug 比较重视,发生后要严肃复盘和分析,并制定措施避免同类问题再次发生。

尽管严重级别是 「 Medium 」和「 Low 」的 bug 数随每月提交次数而增加,但斜率不高,均小于 0.0012。

  • Android: 严重级别为「 Medium 」的曲线斜率为 0.0003,严重级别为「 Low 」的曲线斜率为 0.0012 。

  • iOS: 严重级别为「 Medium 」的曲线斜率为 0.00026,严重级别为「 Low 」的曲线斜率为 0.00097 。

生产环境中的崩溃率

移动端的崩溃率与发布周期没有必然联系。

在下面的图中, Android 在后半期的崩溃率变高,是由于统一调整了 Android 崩溃率的算法,对崩溃量的统计中增加了一些事件类型。

随着发布频率的提高,每次拉发布分支后,正式发布之前,Charry-pick 的数量,以及 launch-blocker 的数量并没有变多,而是稍有减少

发布窗口期的 Launch-blocker

下图中的数据是每次发布窗口期中,平均每天产生的 Charry-pick 个数和 launch-blocker 个数。

需要注意的是, launch-blocker 数量的影响有两个因素:

  1. launch-blocker 的定义声明有主观性;发布工程师说,他们对发布质量的把关越来越严格了;
  2. 2015 年和 2016 年开发了大量的工具,这些工具帮助提高了软件的质量。

不同版本的崩溃率

下图中展示了 Android 不同版本的 崩溃率对于。Android Alpha 版本的崩溃率几乎是正式版本的 10 倍。

注意:图中数据已经归一化处理。

发布窗口期的 Launch-blocker 数量

Cut-day (自动拉 Release 分支)当天,Master 上的提交数量比平日多,如下图所示。

在下图中,横坐标是 Cut-day 当天的提交次数当次发布总提交数的比例,纵坐标相当于每天提交数的Cherry-pick占比。 蓝色三角型为平日,红色圆型为Cut-day。

由图中数据可以看出,随着 Cut-day 当天进行的提交数量的增加,所需的 Cherry-pick 数量也随之增加。

英文参考文献:Continuous Deployment of Mobile Software at Facebook

发表时间: November 13, 2016