【值得收藏】首次披露Facebook移动端软件的持续部署 | IDCF

持续部署是指软件更新一旦准备好就立即发布的实践方法，在业界越来越多地被采用。移动端软件的更新频率普遍落后于基于云端的服务，原因有很多。比如，移动端软件只能定期发布版本；用户可以选择何时升级以及是否升级，这意味着多个不同的版本需要在生产环境中共存；Android设备多种多样，增加了在部署软件时出错的风险。

软件工程/敏捷软件开发

软件配置管理和版本控制系统

软件实施计划

本著作全部或部分的电子版或硬拷贝可用于个人或课堂使用，但不收取任何费用，前提是拷贝不是为了利润或商业利益而制作或分发，且拷贝在第一页上印有本通知的完整的引文。必须尊重除ACM以外的其他人拥有的本作品的权利。允许被授权的摘录。以其他方式复制、再发行、在服务器上发布或重新发布到列表，需要事先获得特定的许可和/或支付费用。

关键词

持续部署；软件发布；移动端代码测试；敏捷开发；持续交付

一、介绍

在本节中，我们将详细描述Facebook针对移动应用开发部署的流程和活动。整体架构如图1所示。有两类活动：开发活动和部署活动。

2.1 开发活动

首先，我们描述一下开发活动。在Facebook，移动端软件和基于云端的软件开发活动实际上没有区别。开发人员从主分支拉出一个local revision control system分支。开发时基于本地分支频繁提交。在经过适当的测试后，当开发人员认为软件更新已经准备好可以部署时，将更新的代码提交到主分支。正如我们在§5中所展示的，每个开发人员每周会向主分支提交3-5次，这个频率与Facebook基于云端的软件等同。

2.2 部署活动

现在，我们描述一下图1的下半部分，部署活动。Facebook有一个发布工程团队(RelEng)负责这些活动。团队中包括负责对应平台的项目经理，他们会对阻塞问题做出判断。

iOS和Android都是以流水线的方式做周期性部署，每个周期天数相同。我们首先描述iOS的具体流程，然后再描述Android的流程的不同之处。 

Facebook收集与每个版本和每个部署相关的大量数据。它保留所有这些数据。在本节中，我们将描述在§5中用于分析的数据集。

3.1 修订控制系统记录

该数据集记录了每次提交和推送、日期、要提交的差异的大小（以LoC度量）、发布差异的开发人员等。

3.2 崩溃（Crash）数据库

FB应用程序崩溃时，崩溃 告会自动发送到FB。崩溃率是应用程序质量的直接指标，这就是为什么要仔细监控这些崩溃 告并用来确定发行版本的运行状况的原因。机器人（Bots）程序会自动将可靠性问题分类为崩溃、软错误、挂起的系统等。每当给定的崩溃率指标高于指定的阈值时，崩溃就会作为启动阻止程序自动提交给任务数据库（如下所述 ）。

此外，会自动将崩溃的应用程序的堆栈跟踪与版本控制系统中记录的最新更改进行比较，如果堆栈跟踪上的任何指令接近已更改的代码，则将以自动方式通知进行更改的开发人员办法。我们按日期和应用程序版本汇总崩溃 告。

3.3 捕蝇器（Flytrap）数据库

该数据库包含（内部或外部）用户提交的问题 告。用户可以从应用程序上的“ 告问题”组件提交问题，该问题可以从下拉菜单或通过摇动设备获得。或者，他们可以在FB 站上填写帮助中心“联系表”。员工生成的捕蝇器会自动输入到任务数据库中（如下所述）。用户生成的捕蝇器不会自动输入到任务数据库中，因为许多用户提交了不重要的问题、新功能请求、各种改进建议，有时只是垃圾。

总体而言，Flytrap数据库非常嘈杂。因此，只有当机器人能够识别足够数量的用户超过给定阈值 告的问题时，用户生成的捕蝇器才会自动输入到任务数据库中。我们按日期和应用程序版本汇总了Flytrap问题。

3.4 任务（Task）数据库

该数据库是发布工程管理系统的核心组件。它记录了将要执行的每个任务以及需要解决的每个问题。任务由人类和机器人输入；机器人创建的任务数量正在迅速增加。与移动版本相关的任务包括：

• 阻碍启动（launch-blocking）问题以RelEng标记的关键问题，需要在部署之前解决。

• 崩溃机器人（crashbot）问题：当崩溃影响超过阈值数量的用户时，bot所创建的任务。

• 捕蝇器（flytrap）问题：由漫游器为员工 告的问题创建的任务，以及超过阈值数量的捕蝇器 告识别出同一问题的任务。

• 测试失败：为失败的自动测试创建的任务（请参见第4节）。

3.5 精选（Cherry-pick）数据库

记录所有精选请求，并标记RelEng接受的请求。我们使用“精选点”的数量作为软件质量的代理指标。

3.6 生产问题数据库

生产代码中标识的所有错误都记录在一个单独的数据库中，并且每个错误都按照严重性进行分类：严重、中优先级和低优先级。当人们认为需要修复生产错误（即使优先级较低）时，记录的错误就会被人输入。我们使用该数据库中的问题数量作为部署到生产中的软件质量的一种度量。

3.7 日活人数（DAP）

该数据库记录使用FB应用程序的用户数。我们按数据和应用程序版本汇总了数字。在某些情况下，我们使用此数据来规范崩溃和捕蝇器质量指标。

3.8 锅炉房

该数据库包含有关每个移动部署的信息，包括部署日期、部署状态、从中进行构建的版本分支、所部署的版本的截止日期、alpha / beta /生产版本等。

3.9 员工数据库

该数据可确定每天有多少开发人员在做移动软件开发。该信息是从提交的日志中提取的：如果开发人员在前两周提交了移动代码，则认为她一直在从事移动软件的开发。

3.10 源代码和配置代码

四、测试

• 测试，当他们运行表1列出了一些类型的测试进行了移动软件。这些测试在开发和部署周期的所有阶段运行。

1）预推试验

开发人员在开发代码时，经常会在自己的 pc / 笔记本电脑上运行单元测试。考虑到应用程序的规模以及 pc 和笔记本电脑的开发能力有限，更广泛的单元测试将在模拟环境中的服务器上运行。开发人员还可以手动调用表中列出的任何其他测试，最常调用的是静态分析和一些集成测试。最后，还有一点，虽然没有单独的测试团队，但在将任何代码推送到主分支之前，都需要对代码进行审查。

2）推送

当开发人员认为他的更改已经完成并且工作正常时，他开始将他的更改推送到 master 分支。在实际的推送发生之前，会自动运行许多测试，以确定是否应该阻塞推送。这些测试包括标准的单元测试以及一些冒烟测试，这些测试可以验证大量使用的特性及其关键流是否正常工作。此外，还运行测试以确保带有更改的构建能够正确工作。但是，由于完整的构建需要大量的时间和资源，这里的构建测试只测试几个级别的依赖性。

如果所有测试都通过，则将更改推送到主分支。合并过程可能会识别冲突，在这种情况下，会通知开发人员，以便他能够处理冲突。

在Master和Release分支上进行连续测试。所有测试都在Master和Release分支上连续运行（每隔几个小时）。其中最重要的是移动设备实验室中的完整构建测试、集成回归测试和性能测试。

正如在2中提到的，Alpha 版本是从 master 分支构建的(ios 每天两次，android 每天一次) ，beta 版本是从 release 分支构建的，每天三次。如果某个百分比的测试失败，Alpha 版软件的发布就会被阻止。这种情况很少发生。

3）人工试验

一个约有100人的手工测试小组用来测试移动应用程序。他们做了各种冒烟测试和边缘情况测试，以确保应用程序按预期运行。测试团队主要用于测试尚未创建自动化测试的新特性。最后，在添加了语言翻译之后，他们负责 UI测试，以评估外观和质量。

五、分析

图2：每个开发人员每天平均推送的代码行数。插入图显示了 2012 年中期以后的相同数据。(来自机器的推送被从数据集中删除，为了避免包含第三方软件包、移动或删除目录而修改了 2000 多行代码的推送也是如此。)

图4：Android和iOs开发团队的规模增长。y轴被故意省略，以免泄露专有信息。 

发现1：即使在代码基础上工作的工程师数量增加了15倍，生产力仍然保持不变。这是Android和iOS开发者的情况，无论是通过LoC推送还是推送的数量来衡量。

对于这种情况的一种假设是，更大的开发组和更复杂的代码库所导致的效率低下，可以通过(i)工具和随时间的推移而进行的自动化改进，以及(ii)所使用的敏捷开发、持续发布和部署过程来抵消。然而，我们可以得出明确的结论:

发现2：脸书移动软件的持续部署过程不会对生产效率产生负面影响，即使开发组织的规模显著扩大。 

5.3 质量

在脸书，每个需要处理的产品环境代码问题都要在产品环境问题数据库中注册，并按严重程度进行分类：

• (i)危急的，“需要立即在高优先级处理的问题；

• (ii)中等优先级处理的问题；

• (iii)低优先级处理的问题”。

我们使用在生产代码中发现的问题的数量作为生产软件质量的一个保证。

图5描述了每个严重级别的问题数量，作为Android和iOS每月推送量的函数。(红色)三角形代表关键的错误，自2012年以来，它们几乎保持不变，每个版本都有0个或1个关键问题。 

发现3：无论决策数量多少，由决策产生的关键问题的数量几乎是不变的。

我们推测，关键问题的数量较少有两个原因：

首先，在测试中更容易发现关键错误；

其次，公司非常重视关键问题，所以每次发生问题后，都会召开一次常务审查会议，以了解问题的根本原因，并确定在未来的部署中如何避免类似的问题。

不出所料，中优先级和低优先级问题的数量与推送量呈线性增长，尽管斜率非常低：对于中优先级问题，斜率分别为0.0003和0.00026，分别适用于Android和iOS。

图6：每个Android(顶部)和iOS(底部)部署的启动阻塞问题的数量(蓝色实线)和挑选的数量(橙色虚线)，根据发布周期的长度进行标准化。

图中的每个数据点描述了每个发布周期中每天平均记录的精选和启动拦截器的数量。垂直的直线显示了发布周期的缩短，先是从4周的节奏减少到2周的节奏，然后是Android的减少到1周的节奏。

我们应该注意到，阻塞启动的数量受到至少两方面的影响。

首先，一个问题是否被宣布为启动阻塞是主观的。RelEng认为，随着时间的推移，他们在决定什么是启动阻滞剂方面已经变得更加严格。这有点直观：随着越来越多的人使用移动应用程序，标准往往会提高。

其次，在2015年和2016年开发了大量的测试工具。这些工具可以提高代码质量，从而减少启动阻塞问题。

图7显示了终端用户每天所经历的崩溃率，为了隐藏ab溶质值，将其标准化为常数。条形图的不同颜色代表不同的版本：每减少一次部署周期，色域就会变得更窄(但在节假日期间可能会更宽)。

发现5：缩短发布周期似乎不影响崩溃率。

2015年上半年，安卓系统的崩溃数量有所增加，这有两个原因。

第一，范围，什么被认为是崩溃扩展到也包括Java崩溃时运行的FB应用程序和应用程序不再回应。

第二，引入了一套第三方软件库，提高了系统的crashrate。今年下半年，一些违规软件被移除。

Facebook内部员工在帮助通过“吃自己的狗粮”来测试移动软件方面发挥了关键作用。iOS平台在内部获得了更好的狗粮覆盖，因为雇员倾向于iOS(而不是Android)。这是一个相当严重的问题，因为Android运行的硬件种类繁多。由于这个原因，Android更多地依赖于其软件的测试版和测试版。

图8显示了alpha版本的有效性。

图8：Android 脸书应用程序的alpha(顶部图)、beta(中间图)和production (bot tom图)版本的正常每日崩溃率：经历崩溃的最终用户与正常为常数的活跃用户总数的比例。

注意，下面的图和上面的图是一样的：图7的图形，只是y轴的比例不同。这些图显示了让用户测试软件的alpha和beta版本以提高软件质量的重要性。

在正常情况下，Android在裁员日的推送比例更低，因此专业人士的选择比例也更小。对此，一个直观的解释是：如果一个开发人员认为他的更新不符合要求，他们只需等待一周，因此不会强制执行。然而，如果下一个削减的幅度更大，那么一些开发人员宁愿强行推进而不是等待更长的时间才能更新部署。

另一个有趣的发现是，将截短日期移到周末可以提高质量，部分原因是当截短日期是周末时，匆忙推送更新的倾向较低。2015年8月安卓和2016年2月iOS的截屏时间从周四改到了周日。而推的平均次数iOS的周末推送量从每天0.3次增加到每天0.5次，Android的周末推送量从每天0.175次增加到每天0.5次(图中未显示)，（6）周末推送量仍明显低于工作日推送量。如图9所示，推动周末削减日的次数越少，与那些发布的樱桃选择的次数越少相关，这是质量提高的标志。 

5.5 影响软件质量的因素

一个有趣的问题，什么因素影响软件质量我们展示了在截止日期推出的软件将会有较低的质量。但我们也证明了把削减日期改到星期天总体上没有影响。开发人员的生产力、发布周期的长度、工程团队的规模、推的数量似乎不会直接影响软件质量。我们找到和软件质量相关的两个因素：

• 每个push变化的大小(以修改后的LoC度量) ；

• 正在更改的文件的大小。

图10：n个开发人员修改时选中文件的比例，n=1..40。

持续部署是从敏捷软件开发[16,17,18,19]到持续集成[20,21,22]到持续交付[7,23]的自然延伸。敏捷开发，软件迭代开发，周期短至半天，开始于20世纪90年代后期，现在在许多组织以不同形式使用着。持续集成是在每个软件周期结束时集成软件更新的做法；这样可以通过自动构建和自动测试来验证集成，以尽快发现集成错误。持续交付可以使公司更进一步，确保可以以随时将其发布到生产环境的方式来构建和测试软件。持续部署在每个软件更改准备就绪后立即将其部署到生产环境中。

相关的开发包括精益软件开发[24]，kanban[25]和kaizan [26]。Devops 是将开发和运营两方面的角色和工具结合起来的行动[27，28]。

在最近的一项研究中，mcilroy 等人指出，在 google play 商店中的10713个移动应用程序(2013年初 google play 商店30个类别中的前400个免费应用程序)中，1% 的应用程序部署频率超过一周一次，14% 的应用程序至少每两周部署一次。虽然这项研究基于一个相对较小的时间范围，但它表明许多组织正在积极进行持续部署。

然而，文献中只有有限的明确提到了移动软件的持续部署。Klepper 等人扩展了他们的敏捷过程模型，以适应移动应用[30]。Etsy 是持续集成的负责人，在会谈中介绍了他们如何对移动应用程序进行持续集成; 很高效，他们每天将更新下发到每个员工移动终端

关于测试，Kamei等。评估即时质量保证[33]，类似于第4节中描述的策略。高Gao et al. 讲解移动测试作为移动软件开发的一个基础服务[34]。亚马逊的Appthwack为此提供了一个移动设备平台[35]。

七、结束语

参考

[1] T. Savor, M. Douglas, M. Gentili, L. Williams, K. Beck, and M. Stumm, “Continuous deployment at Facebook and OANDA,” in Proc. 38th Intl. Conf. on Software Engineering, (ICSE16), May 2016, pp. 21–30.

[2] C. Parnin, E. Helms, C. Atlee, H. Bought, M. Ghattas, A. Glover, J. Holman, J. Micco, B. Murphy, T. Savor, M. Stumm, S. Whitaker, , and L. Williams, “The top 10 adages in continuous deployment,” IEEE Software, accepted for publication, 2016. 

[3] J. Allspaw and P. Hammond, “10 deploys per day — Dev and Ops cooperation at Flickr,” 2009, slides. [Online]. Available: http://www.slideshare.net/jallspaw/ 10-deploys-per-day-dev-and-ops-cooperation-at-flickr 

[4] M. Brittain, “Continuous deployment: The dirty details,” Jan. 2013. [Online]. Available: http://www.slideshare.net/mikebrittain/ mbrittain-continuous-deploymentalm3public 

[5] T. Schneider, “In praise of continuous deployment: The WordPress.com story,” 2012, 16 deployments a day. [Online]. Available: http://toni.org/2010/05/19/ in-praise-of-continuous-deployment-the–word -press–com–story/ 

[6] G. Gruver, M. Young, and P. Fulgham, A Practical Approach to Large-scale Agile Development — How HP Transformed LaserJet FutureSmart Firmware. Addison-Wesley, 2013. 

[7] J. Humble and D. Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley, 2010. 

[8] D. Feitelson, E. Frachtenberg, and K. Beck, “Development and deployment at Facebook,” IEEE Internet Computing, vol. 17, no. 4, pp. 8–17, 2013. 

[9] A. Reversat, “The mobile device lab at the Prineville data center,” https://code.facebook.com/posts/300815046928882/ the-mobile-device-lab-at-the-prineville-data-center, Jul. 2016. 

[10] https://www.chef.io/chef/. 

[11] https://developer.apple.com/reference/xctest. 

[12] http://junit.org/. 

[13] http://robolectric.org. 

[14] P. Steinberger, “Running UI tests on iOS with ludicrous speed,” https://pspdfkit.com/blog/2016/ running-ui-tests-with-ludicrous-speed/, Apr. 2016.

[15] https://github.com/facebook/ios-snapshot-test-case/. 

[16] K. Beck, Extreme Programming Explained: Embrace Change. Addison-Wesley, 2000. 

[17] K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C. Martin, S. Mellor, K. Schwaber, J. Sutherland, and D. Thomas, “Manifesto for agile software 22 development,” 2001. [Online]. Available: http://www.agilemanifesto.org/ 

[18] A. Cockburn, Agile Software Development. Addison Wesley Longman, 2002. 

[19] A. Cockburn and L. Williams, “Agile software development: It’s about feedback and change,” Computer, vol. 36, no. 6, pp. 39–43, 2003. 

[20] L. Williams, “Agile software development methedologies and practices,” in Advances in Computers, vol. 80, 2010, pp. 1–44.

[21] M. Fowler and M. Foemmel, “Continuous integration,” Thought-Works) http://www.thoughtworks.com/Continuous Integration.pdf, p. 122, 2006. 

[22] P. M. Duvall, Continuous Integration. Pearson Education India, 2007. 

[23] L. Chen, “Continuous delivery: Huge benefits, but challenges too,” IEEE Software, vol. 32, no. 2, pp. 50–54, 2015. 

[24] M. Poppendieck and M. A. Cusumano, “Lean software development: A tutorial,” IEEE software, vol. 29, no. 5, pp. 26–32, 2012. 

[25] D. J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010. 

[26] M. Poppendeick and T. Poppendeick, Lean Software Development. Addison Wesley, 2002. 

[27] M. Httermann, DevOps for developers. Apress, 2012. 

[28] J. Roche, “Adopting DevOps practices in quality assurance,” Communications of the ACM, vol. 56, no. 11, pp. 38–43, 2013. 

[29] S. McIlroy, N. Ali, and A. E. Hassan, “Fresh apps: an empirical study of frequently-updated mobile apps in the google play store,” Empirical Software Engineering, vol. 21, no. 3, pp. 1346–1370, 2016. 

[30] S. Klepper, S. Krusche, S. Peters, B. Bruegge, and L. Alperowitz, “Introducing continuous delivery of mobile apps in a corporate environment: A case study,” in Proceedings of the Second International Workshop on Rapid Continuous Software Engineering, ser. RCoSE ’15, 2015, pp. 5–11. [Online]. Available: http://dl.acm.org/citation.cfm=2820678.2820681 

[31] J. Miranda, “How Etsy does continuous integration for mobile apps,” https://www.infoq.com/news/2014/11/ continuous-integration-mobile/, Nov. 2014. 

[32] K. Nassim, “Etsy’s journey to continuous integration for mobile apps,” https://codeascraft.com/2014/02/28/ etsys-journey-to-continuous-integration-for-mobile-apps/, Nov. 2014. 

[33] Y. Kamei, E. Shihab, B. Adams, A. E. Hassan, A. Mockus, A. Sinha, and N. Ubayashi, “A large-scale empirical study of just-in-time quality assurance,” IEEE Transactions on Software Engineering, vol. 39, no. 6, pp. 757–773, 2013. 

[34] J. Gao, W.-T. Tsai, R. Paul, X. Bai, and T. Uehara, “Mobile Testing-as-a-Service (MTaaS) — Infrastructures, issues, solutions and needs,” in 2014 IEEE 15th International Symposium on High-Assurance Systems Engineering, 2014, pp. 158–167. 

[35] https://aws.amazon.com/device-farm.

译者：IDCF 区翻译组