推广思路及执行方案,利用店铺网站做灰色优化,wordpress远程自动下载图片大小,墨猴seo排名公司#xff08;图片来源于网络#xff09;摘要持续部署是指软件更新一旦准备好就立即发布的实践方法#xff0c;在业界越来越多地被采用。移动端软件的更新频率普遍落后于基于云端的服务#xff0c;原因有很多。比如#xff0c;移动端软件只能定期发布版本#xff1b;用户可… 图片来源于网络摘要持续部署是指软件更新一旦准备好就立即发布的实践方法在业界越来越多地被采用。移动端软件的更新频率普遍落后于基于云端的服务原因有很多。比如移动端软件只能定期发布版本用户可以选择何时升级以及是否升级这意味着多个不同的版本需要在生产环境中共存Android设备多种多样增加了在部署软件时出错的风险。Facebook在提升移动端软件部署频率方面取得了重大进展在4年的时间里Android版本从每8周发布一次变成了每1周发布一次。本文中我们详细描述了Facebook移动端软件的部署过程。我们基于7年时间内搜集的数据对软件工程指标进行广泛分析提出我们的研究结果。一个关键的发现是部署的频率并不直接影响开发人员的生产效率或软件质量。我们认为这个发现是由于增加持续部署的频率可以促进发布和部署的自动化从而减少开发人员的工作量导致的。此外我们提供的数据表明从Alpha版本和Beta版本的试用客户那里获得反馈对于保持发布质量至关重要。软件工程/敏捷软件开发软件配置管理和版本控制系统软件实施计划本著作全部或部分的电子版或硬拷贝可用于个人或课堂使用但不收取任何费用前提是拷贝不是为了利润或商业利益而制作或分发且拷贝在第一页上印有本通知的完整的引文。必须尊重除ACM以外的其他人拥有的本作品的权利。允许被授权的摘录。以其他方式复制、再发行、在服务器上发布或重新发布到列表需要事先获得特定的许可和/或支付费用。版权归所有者/著作者所有。授权给ACM出版。关键词持续部署软件发布移动端代码测试敏捷开发持续交付一、介绍持续部署是一种将软件增量在准备就绪后就更新到生产环境中的工程实践。持续部署在业界正变得越来越普遍并具有诸多优势包括更小的增量式变更带来的低风险更多来自最终用户的快速反馈以及对安全漏洞等威胁的更快速的响应能力。在之前的一篇文章中我们描述了基于云端软件的持续部署过程即Facebook和另外一家公司的Web前端和服务端的SAAS软件点击回顾????16800字|从Facebook到OANDA持续部署一文全解析。我们介绍了它的实施过程和一些经验。在Facebook每个部署的软件更新平均有92行代码LoC被添加或修改每个开发人员平均每周向生产环境推送3.5次更新。考虑到Facebook工程团队的规模这意味着每天会向生产环境部署1000次。在提到的两家公司中开发人员对软件更新完全负责他们没有就是这么设计的单独的测试团队开发人员负责测试自己的代码只是在代码提交之前需要进行同行评审。但是对于测试和质量有大量的自动化支持只要开发人员认为软件已经准备就绪就可以把发布代码并将其部署到生产环境中。正如在前一篇文章中演示的基于云端的软件环境允许众多小的增量部署部分原因是部署不会给最终用户带来不便。此外环境支持很多特性以管理可能导致部署错误的风险包括蓝绿部署、功能发布开关和灰度发布。即使最坏的情况只需要按下一个按钮就可以“回滚”到任何最近部署的更新将模块恢复到以前的版本。与之前相比在本文中我们描述并分析了持续部署如何应用于Facebook的移动端软件。Facebook移动端软件每天超过10亿人使用软件部署的关键挑战在于不可能像基于云的服务那样进行持续部署原因如下软件更新的频率可能是有限的因为移动平台上的软件更新对终端用户来说不完全透明平台的应用审核也需要时间。例如苹果对iOS应用的审核。软件不能按照模块部署。只能作为一个整体进行部署这会增加部署的风险。降低风险的措施有限。例如热修复和回滚在很大程度上是不可接受的只能在极端情况下使用因为涉及到与发布平台的协作如苹果。最终用户可以选择何时升级如果允许的话这意味着不同版本的软件在同时运行时要能够正常工作。不同的硬件种类特别是Android平台以及需要支持多个不同版本的操作系统。笛卡尔乘积应用的版本数量操作系统类型和版本硬件平台数量导致每次部署的风险都大大增加。考虑到上述限制一个有力的开放式问题出现了: 如何能够“持续”进行移动端软件的部署。Facebook正在努力挑战极限尽可能接近移动端软件的持续部署。关键的策略是将软件开发、发布与实际的部署解耦前者经常以小型增量出现而后者只是周期性出现。特别是开发人员将移动端软件以和云端软件相同的频率进行更新以类似大小的增量提交到Master分支。只要开发人员认为他们的软件已经可以部署他们就会这样做。然后定期从Master分支中切分出一个发布分支对于Android是每周一次对于iOS则是两周一次。这个分支中的代码经过了大量的测试并进行必要的修复后向公众发布。在Facebook中应用的完整流程在第2节中详细描述。接下来的一个重要问题是与更连续的云端软件部署过程相比移动端软件部署过程如何影响开发生产效率和软件质量?在5.2节中我们展示了无论以修改或增加的代码行还是以每天提交次数为度量指标的生产效率都与Facebook相当。即使移动端工程师团队增长了15倍甚至软件随着功能增加变得更加复杂移动端软件开发生产效率仍然保持不变。事实上在4年时间里Android端从每8周部署一次到每1周部署一次对程序员的工作效率没有明显的影响。测试对移动端应用尤其重要因为在部署后出现关键问题时可供采取的补救措施有限(与基于云端的软件相比)。我们在第4节中描述了许多在Facebook中用于移动端代码的测试工具和流程。我们在5.5节中展示了Facebook移动端软件的质量要高于Facebook中所有软件的平均质量。我们发现移动端软件代码的质量并没有随着开发团队的规模增长、产品的成熟和复杂、发布周期的缩短而恶化。事实上一些度量指标表明质量会随着时间的推移而提高。最后我们在第5节展示了经过分析的调查结果。例如我们提出在发布分支被切分出来的当天软件更新的平均质量较低。我们还表明在同一代码文件上工作的开发人员的数量越多软件质量就越低。我们研究的一个重要方面是我们的分析基于大量的数据 (第3节)。从2009年1月至2016年5月包括来自版本控制系统的所有提交日志、所有应用程序崩溃记录、Facebook员工和客户报告的所有问题以及发布过程中确定的所有关键问题。在2012年以前的数据中有意义的结论相对较少因为那时处于移动端软件的早期阶段专门从事移动端软件开发的人员相对较少。2012年Facebook首席执行官在旧金山的TechCrunch Disrupt大会上向公众宣布了公司的“移动端优先”战略。从那时起移动端开发团队显著增长收集的数据变得更加完整和有意义。因此我们提供的大部分数据都是针那段时间的。综上所述本文的具体贡献如下:据我们所知我们第一个描述了移动端软件的持续部署流程。具体来说是指Facebook的移动端软件持续部署流程。这是首次对Facebook的移动端软件测试策略进行描述和评估。我们基于7年间搜集的与移动端软件相关的数据对生产效率和软件质量进行了全面分析。我们能够证明快速的发布周期不会对开发人员的生产效率或软件质量产生负面影响。我们相信我们第一个提出了以下两个引人注目的发现(i) 修改同一个代码文件的开发人员数量与该代码文件对应的软件质量成反比(ii) 在从Master分支中切分出发布分支的当天提交的代码质量要低于其他日期提交的代码质量。在下一节中我们将介绍Facebook中Android和iOS端软件的发布周期。第3节展示我们搜集的用于分析的数据。第4节描述使用的测试策略。在第5节中我们提供分析结果。在第6节介绍其他相关的工作。最后我们会用一篇结束语来结束。二、移动应用的发布周期在本节中我们将详细描述Facebook针对移动应用开发部署的流程和活动。整体架构如图1所示。有两类活动开发活动和部署活动。2.1 开发活动首先我们描述一下开发活动。在Facebook移动端软件和基于云端的软件开发活动实际上没有区别。开发人员从主分支拉出一个local revision control system分支。开发时基于本地分支频繁提交。在经过适当的测试后当开发人员认为软件更新已经准备好可以部署时将更新的代码提交到主分支。正如我们在§5中所展示的每个开发人员每周会向主分支提交3-5次这个频率与Facebook基于云端的软件等同。2.2 部署活动现在我们描述一下图1的下半部分部署活动。Facebook有一个发布工程团队(RelEng)负责这些活动。团队中包括负责对应平台的项目经理他们会对阻塞问题做出判断。iOS和Android都是以流水线的方式做周期性部署每个周期天数相同。我们首先描述iOS的具体流程然后再描述Android的流程的不同之处。 图1iOS发布周期整个两周的过程中每个阶段都是在流水线中(iOS移动代码)基于发布分支的稳定性测试、性能测试、代码评审和部署需要两周时间而在这两周里新的软件代码会不断被提交到主分支直到从主分支中拉出下一个发布分支。对于iOS来说发布工程团队会以两周为周期在第二个周日的下午6点从Master分支中拉出一个Release分支。Release分支首先要稳定运行5天在此期间对问题进行修复并做一些优化和稳定性方面的更新。那些被发布工程团队归类为影响最终用户使用的阻塞性Bug必须在部署之前修复。最后发布工程团队可以通过将部分代码恢复到以前的版本来绕过一些问题。开发人员负责解决发布工程团队提出的任何问题比如已确定的bug。开发人员在解决问题所做的任何更新包括Bug修复、优化和稳定性更新都需要提交合并到Master分支。然后开发人员必须请求发布工程团队将主分支的更新合并到发布分支中并解释为什么需要合并。接下来发布工程团队根据自身判断将更新的代码合并到Release分支。他们会考虑各种风险因素进行谨慎的分析判断合并代码的请求可能因为各种原因被发布工程团队拒绝。举两个因为合并风险过高而被拒绝的例子有太多依赖比如超过5个的更新和对核心组件如网络和显示做出重大更改的更新。最终发布工程团队会权衡风险和影响做出判断。例如一个影响较小的优化类更新在前2-3天是可以接受的之后就会被拒绝合并。在上述的稳定阶段通过Release分支构建的App会像“狗粮”一样提供给Facebook内部用户使用每天会提供三次。经过5天的稳定期代码会被冻结开始进行为期3天的性能测试。在性能测试期间只接受阻塞性问题的修复。最后在创建Release分支后的第二个周一会提交软件到苹果公司审核并在那周的晚些时候发布。在整个过程中如图1所示在当前Release分支稳定的同时新的更新代码被提交到Master分支。这些更新只有一部分会被发布工程团队合并到Release分支中。不论出于什么原因如果图右半部分所示的两周不能安全的完成就会停止部署所有的代码更新都会被推迟到下一次的定期部署。Android的发布周期和iOS基本一样只是拉Release分支的周期由2周被压缩至1周。周四冻结代码只接受阻塞性问题的修改。在周一早晨拉出Release分支后的那周App通过应用商店分批逐步分发给用户通常是在接下来的三天内分别推送20%、50%和100%的用户。每增加一次推送用户比例都需要定期进行稳定性检查。对于Android来说Facebook也会发布Alpha和Bate测试版App。Alpha版本每天从Master分支构建通过Google Play Store分发给一小部分外部用户通常小于10000用户。Bate版本每天从Release分支构建并提供给更多的外部用户大约300万。发布工程团队发布工程团队在上述过程中扮演着关键的角色。尽管它很重要这个团队可能比人们想象中要小——只有不到10个成员。高级别的产品开发人员不断被借调到发布工程团队临时工作每次大约2个月时间。这种安排的一个核心优势是在发布工程团队和开发团队间建立了合作伙伴关系。开发人员开始了解发布工程团队在做什么流程是什么有哪些问题和痛点等等。开发人员在发布工程团队工作期间积累的知识会在回到团队后传授给其他成员。这种安排的另一个好处是开发人员在发现发布过程效率低下之后在某些情况下会为发布工程团队开发工具从而使发布过程进一步简化和自动化。三、数据搜集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 源代码和配置代码我们使用来自该来源的信息来确定自动化作业的计划方式和时间、以及机器人用来确定何时创建任务的阈值等。四、测试测试对于移动应用来说尤其重要原因如下每周对移动软件进行成千上万次更新 必须进行数百种设备和操作版本组合在部署后出现严重问题时可采取的补救措施很有限。正如人们可能期望的那样FB应用了多种类型的测试包括单元测试、静态分析测试、集成测试、屏幕布局测试、性能测试、构建测试以及手动测试。工具和自动化起着关键的作用数百名工具开发人员给我们提供了支持。大多数测试以自动化方式运行。当检测到回归时会尝试将其自动绑定到最近进行的特定代码更改然后自动将电子邮件发送给负责该特定更改的开发人员。在我们描述一些测试之前以及何时进行测试简要介绍了可用的测试基础架构FB以及指导FB测试的原则策略。4.1 测试基础架构数千个计算节点专用于测试移动软件。通过在模拟和仿真环境中运行测试可以应用白盒和黑盒测试策略。为了在真实硬件上进行测试FB运行着真实的移动设备。位置在Prineville数据中心的实验室[9]。移动实验室主要用于测试性能下降主要关注应用速度内存使用情况和电池效率。移动实验室包含电磁隔离的机架。每个机架放置多个测试设备iOS 和Android。节点将安装、测试和卸载目标软件。Chef是一种配置管理工具[10]用于配置-设备。机架中的无线接入点支持设备Wi-Fi通信。设备放置在机架上以便它们的屏幕可以被摄像机捕获。工程师可以远程访问摄像机以观察每个设备都会对代码更改做出反应。因此实验室有效提供测试基础架构即服务。4.2 Testing Principles at FBFB的测试原理FB的测试策略包括以下原则测试范围。测试范围尽可能的全面所有已编写还在运行的都应该测试。尽可能合理地开展测试工作。快速响应。捕获回归的速度越快处理起来就越容易快速捕获的问题更容易被开发人员解决因为代码和代码结构仍然是最重要的。例如使用并行构建以便能够更快地提供反馈。目标是能够在开发完成后10分钟内向其提供冒烟测试的结果。质量。测试应辨认出首要问题。精确误报和错报需要被最小化。这很重要不仅能最大程度地减少开发人员花费在追踪错误警报上的时间并且还能防止测试时间超时。自动化。测试尽可能地自动化。这使得它们可重复使用并确保测试能够定期运行。自动化的另一个方面已经被证明是有用的: 自动识别导致代码变更的开发人员以便他能够立即被告知关于检测到的问题和可能导致问题的代码的具体细节。这是通过比较代码中可能导致检测到的问题的位置与最近应用的代码更改来实现的。由于这种能力只有在质量高的时候才有效因此人们已经投入了大量的精力来发展这种能力。优先次序。测试需要大量的计算资源如果它是详尽的并在同一时间响应。由于资源总是有限一个优化过的测试策略是必须的。例如当一个更改被推送到主分支时集成测试只在应用程序中那些可能被推送的更改影响的部分进行而不是运行整个测试套件。这使得更快地向开发人员提供关键测试结果成为可能。完整的集成测试每隔几个小时在主分支和发布分支上运行一次。表1: 对移动软件进行的测试范围测试当他们运行表1列出了一些类型的测试进行了移动软件。这些测试在开发和部署周期的所有阶段运行。1预推试验开发人员在开发代码时经常会在自己的 pc / 笔记本电脑上运行单元测试。考虑到应用程序的规模以及 pc 和笔记本电脑的开发能力有限更广泛的单元测试将在模拟环境中的服务器上运行。开发人员还可以手动调用表中列出的任何其他测试最常调用的是静态分析和一些集成测试。最后还有一点虽然没有单独的测试团队但在将任何代码推送到主分支之前都需要对代码进行审查。2推送当开发人员认为他的更改已经完成并且工作正常时他开始将他的更改推送到 master 分支。在实际的推送发生之前会自动运行许多测试以确定是否应该阻塞推送。这些测试包括标准的单元测试以及一些冒烟测试这些测试可以验证大量使用的特性及其关键流是否正常工作。此外还运行测试以确保带有更改的构建能够正确工作。但是由于完整的构建需要大量的时间和资源这里的构建测试只测试几个级别的依赖性。如果所有测试都通过则将更改推送到主分支。合并过程可能会识别冲突在这种情况下会通知开发人员以便他能够处理冲突。在Master和Release分支上进行连续测试。所有测试都在Master和Release分支上连续运行每隔几个小时。其中最重要的是移动设备实验室中的完整构建测试、集成回归测试和性能测试。正如在2中提到的Alpha 版本是从 master 分支构建的(ios 每天两次android 每天一次) beta 版本是从 release 分支构建的每天三次。如果某个百分比的测试失败Alpha 版软件的发布就会被阻止。这种情况很少发生。3人工试验一个约有100人的手工测试小组用来测试移动应用程序。他们做了各种冒烟测试和边缘情况测试以确保应用程序按预期运行。测试团队主要用于测试尚未创建自动化测试的新特性。最后在添加了语言翻译之后他们负责 UI测试以评估外观和质量。五、分析5.1 方法我们对脸书移动软件工程的定量分析是基于$3的数据描述。从这些数据集中提取的数据被清洗、解释、交叉检查得出的结论被提交给脸书内部的主题专家进行确认。我们描述了数据集是如何在相关的图标题中被清理的。一些数据集是从 2009 年 1 月开始的。一直持续到 2016 年。2009 年至 2012 年期间收集的指标相当嘈杂以至于很难推断出有用的见解。本节的前几张图描述的是 2009 年以后的数据后面几张图描述的是 2012 年到 2016 年的数据。在 2012 年开发移动端代码的开发人员不足 100 人而到 2016 年开发移动端代码的开发人员已超过 1500 人。每天有超过十亿的用户使用这个软件。图2每个开发人员每天平均推送的代码行数。插入图显示了 2012 年中期以后的相同数据。(来自机器的推送被从数据集中删除为了避免包含第三方软件包、移动或删除目录而修改了 2000 多行代码的推送也是如此。)图3每个开发人员平均每天的推送量。(从数据集中删除了来自机器的推送。) 5.2 开发人员的生产力图2描述了开发人员的生产力这是通过代码行(LOC)来度量的最终平均每个开发人员和每天推送和部署代码行。该图显示对于Android和iOS开发人员平均每天生成70个LoC。这与全公司范围内所有软件中每个开发人员每天产生的 64.5 LoC 是一致的(5)。后台服务的代码生成速度比平均速度慢。图3描述了Android 和 iOS 每天的平均推送量。在过去两年中每个开发者平均每天的推送量分别为 0.7 和 0.8。在全公司范围内的软件中平均每个开发者每天的工作量是 0.7因此iOS 的推送更加频繁。虽然 Android 每天每个开发者的推送量少于 iOS但它每天每个开发者生成的 LoC 数量与 iOS 相同这意味着 Android 的推送量略大于 iOS。比绝对数字更有趣的是开发人员为移动平台编写代码的数量是如何随时间变化的——图4描述了这些开发人员的数量是如何随时间变化的:图4Android和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。图52011年3月至2016年5月期间Android和iOS产品代码的问题记录数量与每月推送量的函数关系。最上面的图表是Android的iOS的底部。注意x轴和y轴的比例非常不同所有的线性趋势线的斜率都小于0.0012。对于低优先级问题Android和iOS的斜率分别为0.0012和0.00097。中、低优先级问题的倾斜度在Android上都高于iOS相对大量的Android硬件平台可能是一个潜在的解释。有趣的是在整个公司范围内所有的软件这两个相应的斜坡分别是0.0061和0.0013这两个斜坡都比移动代码更陡。总的来说我们认为这些数据证明了应用于移动软件的测试策略是有效的。图6显示了针对Android和iOS的每个部署的启动阻塞问题的数量和挑选的数量。为了便于直接比较这些数字是根据发布周期的长度进行规范化的这是基于这样一个假设一个长两倍的发布周期将有两倍的push和两倍的LoC修改。也就是说图中的每个数据点描述了平均年龄每天记录的精选和发射阻滞剂的每个释放周期数。总的来说启动阻滞剂的数量和挑选的数量似乎会随着时间的推移而有所波动但没有特别的趋势。挑选的数量似乎主要停留在Android的5-25和iOS的5-15之间。 发现4部署周期的长度不会显著影响挑选和启动阻滞剂的相对数量因为它从4周减少到2周(然后是Android的1周)。由此我们得出结论使用所描述的持续部署过程部署周期的长度不会直接影响所生成软件的质量。特别是在部署频率变化的点上曲线没有不连续。图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版本的有效性。图7Android顶部图和iOS(底部图)的标准化日崩溃率经历崩溃的最终用户与被标准化为常数的活动用户总数的比例。垂直的直线显示了发布周期缩短的地方首先从4周缩短为2周然后是Android缩短为1周。为了隐藏绝对值而允许比较曲线被归一化为相同的常数。 关于崩溃从alpha到beta的崩溃率明显下降在软件的beta版本中偶尔出现的崩溃率峰值不再出现在软件的生产版本中。软件的alpha版本的崩溃率大约比产品版本高10倍。 5.4 最后期限的影响在释放分支被切断的那一天向主分支推送的次数明显增加。这可能表明开发人员急于在截止日期前提交他们的代码这就引出了一个问题在发布日提交的代码质量是否下降了?图9描述了每一次推送选择的数量作为发布分支被削减当天推送比例的函数。挑选的数量被用作软件质量的代理。在发布日所做的推送的百分比和每天所选的樱桃数量之间存在相关性随着发布日所做的推送的数量的增加所需要的樱桃数量也随之增加。从绝对意义上讲Android在“剪切日”的推送比例更高。这主要是因为许多数据点表示以一周为周期的发布而所有iOS数据点表示以两周为周期的发布。也就是说如果所有的Android推送都均匀地分布在七天里那么每天会有14%的推送另一方面如果iOS推送在14天内均匀分布那么每天的推送量应该占总推送量的7%。 发现6在最后期限当天推出的软件质量较低。我们的假设是在削减日推出的软件很可能是匆忙的匆忙的软件将有较低的质量。图8Android 脸书应用程序的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度量) 正在更改的文件的大小。图9每一次推送的选择与发布截止日期的推送比例的函数。周四的截线显示为红色的圆圈星期天的时候切成三角形。对于Android来说只能在2014年6月之后发布——包括在内。也就是发行周期转变为两周节奏的时候。对于iOS来说只有在2014年9月之后的版本才会被包括在内也就是在那个时候发布周期才会切换到两周的节奏。截至2016年5月底的版本同时适用于Android和iOS。然而我们确实发现了两个影响软件质量的因素尽管这两个因素高度相关。首先我们发现随着将mit代码添加到发布文件的开发人员数量的增加文件被挑选出来的概率也随之增加。如图10所示。 发现7越多的开发人员参与修改一个版本的文件这个文件的软件质量就越低。有些文件的修改量大得惊人。这种情况自然发生的一个示例场景是非常大的switch语句其中与各个case语句相关的代码由不同的开发人员修改。图10n个开发人员修改时选中文件的比例n1..40。图11在n1.40的情况下提交n次时选中的文件的比例。上述发现表明文件需要修改-由多个开发商可能应该分裂以改善质量。我们发现影响软件质量的第二个因素是一个文件在剪切之间被推送的次数。推的数量越多文件被挑选的可能性就越大(图11)。但是请注意大量开发人员修改文件意味着大量的文件推送。六、相关工作持续部署是从敏捷软件开发[16,17,18,19]到持续集成[20,21,22]到持续交付[7,23]的自然延伸。敏捷开发软件迭代开发周期短至半天开始于20世纪90年代后期现在在许多组织以不同形式使用着。持续集成是在每个软件周期结束时集成软件更新的做法这样可以通过自动构建和自动测试来验证集成以尽快发现集成错误。持续交付可以使公司更进一步确保可以以随时将其发布到生产环境的方式来构建和测试软件。持续部署在每个软件更改准备就绪后立即将其部署到生产环境中。相关的开发包括精益软件开发[24]kanban[25]和kaizan [26]。Devops 是将开发和运营两方面的角色和工具结合起来的行动[2728]。在最近的一项研究中mcilroy 等人指出在 google play 商店中的10713个移动应用程序(2013年初 google play 商店30个类别中的前400个免费应用程序)中1% 的应用程序部署频率超过一周一次14% 的应用程序至少每两周部署一次。虽然这项研究基于一个相对较小的时间范围但它表明许多组织正在积极进行持续部署。然而文献中只有有限的明确提到了移动软件的持续部署。Klepper 等人扩展了他们的敏捷过程模型以适应移动应用[30]。Etsy 是持续集成的负责人在会谈中介绍了他们如何对移动应用程序进行持续集成; 很高效他们每天将更新下发到每个员工移动终端关于测试Kamei等。评估即时质量保证[33]类似于第4节中描述的策略。高Gao et al. 讲解移动测试作为移动软件开发的一个基础服务[34]。亚马逊的Appthwack为此提供了一个移动设备平台[35]。七、结束语本文描述了 Facebook 移动应用程序的持续部署。更短的发布周期有许多优点包括更快的上线时间和更好的响应用户反馈的能力等等。在四年的时间里Android 的发布周期从8周缩短为1周。我们描述了这段时间学到的东西。缩短发布周期迫使组织改进工具、自动化测试和过程。我们观察到在 Android 发布周期从8周减少到1周的四年时间里这些改进工具和提高自动化程度的努力代表了使持续部署成功的大部分工作。所收集的数据表明工具和流程的改进提高了质量并允许更快的发布周期。然而持续部署本身并没有提供任何生产力或质量改进。发布用于移动平台的软件更加困难因为在出现问题的情况下不可能像云软件那样回滚/前进。功能标记用于远程启用或禁用功能以便有故障的功能不需要新版本。如果自动报告此类问题则Alpha和Beta程序在提供可减少问题的错误报告方面非常有效。分析显示出几种导致软件质量降低的模式一个人在分支日期忙于发布发现发布分支被切断的当天提交的软件质量较低。缩短发布周期改善了这一点因为知道即将发布另一个版本开发人员不太可能匆忙进行软件开发。导致软件质量降低的另一种模式是有太多的开发人员同时在同一个文件上工作发现每个文件的问题数量与修改文件的开发人员数量成比例地增加。八、致谢我们衷心感谢Laurent CharignonScott ChouAmanda DonohueBen HolcombDavid MortensonBryan O’SullivanJames PearceAnne RuggirelloDamien Sereni和Chip Turner所做的宝贵贡献建议和反馈。他们的意见极大地改善了本文。参考[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?id2820678.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社区翻译组
