用数据说话：即使提高发布频率，质量与产量也能兼得！

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

在上一篇文章《 移动端的持续交付实践》中，我们描述了移动端（包括 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