ACM通信

实践

连续交付听起来不错，但它在这里能奏效吗?

作者:Jez Humble
ACM通信，2018年4月，第61卷第4期，34-39页
10.1145 / 3173553
评论

持续交付是一套原则、模式和实践，旨在使部署(无论是大规模分布式系统、复杂的生产环境、嵌入式系统还是移动应用程序)可预测、可随时按需执行的常规事务。本文介绍了持续交付，提出了实现它的常见反对意见和实际障碍，并通过实际例子描述了如何克服这些障碍。

持续交付的目标是能够以一种可持续的方式安全地、快速地将所有类型的更改(包括新特性、配置更改、bug修复和实验)交付到生产中，或交付到用户手中。

通常认为，更频繁地部署软件意味着在系统中接受较低的稳定性和可靠性级别。事实上，同行评议的研究表明，事实并非如此;高绩效的团队始终比低绩效的竞争对手更快、更可靠地交付服务。即使在金融服务和政府等高度监管的领域，情况也是如此。

这种能力为愿意投入精力追求它的组织提供了竞争优势。它允许团队在准备就绪时交付新特性，与真正的客户测试工作原型，并构建和发展更稳定、更有弹性的系统。实施持续交付也被证明可以减少不断发展的产品和服务的持续成本，提高它们的质量，并减少团队的疲劳。

虽然连续部署在美国，持续发布每一个好的软件版本的做法，主要局限于云或数据中心托管的服务，持续交付这里描述的支持持续部署的实践集可以应用于任何领域。

一系列的原则和实践形成了持续交付的经典https://continuousdelivery.com）.

回到顶部

对连续交付的常见反对意见

虽然人们可能知道连续交付，但他们通常认为“这在这里行不通”。最常见的反对意见如下:

• 在高度管制的环境中工作时，不适合连续传送。
• 连续投递只适用于网站。
• 持续交付实践不能应用于遗留系统。
• 持续交付需要比这里更有经验和才能的工程师。

在这里，我将检查和揭穿这些说法，然后讨论真正的实现持续交付的障碍:不充分的架构和非生成文化。

在高度管制的环境中工作。反对在受监管的环境中使用持续交付的意见通常有两种:第一，毫无根据的认为持续交付在某种程度上“更有风险”的看法;第二，许多法规的编写方式不容易与持续交付的实践相协调的事实。

持续发布以某种方式增加风险的想法与持续发布以减少发布风险和数据的整个动机是直接矛盾的。4年的数据表明，高绩效人员在吞吐量和稳定性方面都达到了高水平。²这是可能的，因为持续交付的核心实践——全面的配置管理、持续的测试和持续的集成——允许快速发现代码中的缺陷、环境中的配置问题和部署过程中的问题。

在持续交付中，在整个部署管道中频繁地执行对类生产环境的自动化部署，并针对因此部署的构建运行全面的自动化测试，从而对所构建的软件既可部署又适合于目的有更高的信心。

相比之下，许多组织采用的风险降低策略在实践中相当于剧院:无尽的电子表格、核对表和会议的设计更多地是为了确保流程得到遵循，而不是实际上减少部署流程的痛苦和风险。所有这一切并不是说，更传统的风险管理流程在做好的情况下就不能发挥作用。相反，这表明持续交付提供了一种替代的风险管理策略，该策略已被证明至少同样有效，同时还支持更频繁的发布。

持续交付与共同监管制度不一致的观点也值得进一步审视。许多关于控制的实现的指导，旨在满足监管目标，假设不频繁的发布和传统的分阶段软件交付生命周期与功能竖井完成。然而，在连续范式中满足控制目标通常也是可能的。Amazon就是一个例子，它在2011年平均每11.6秒发布一次生产变更，一小时内多达1,079次部署(在整个Amazon生产环境中汇总)。⁵作为一家处理大量信用卡交易的上市公司，亚马逊同时受萨班斯-奥克斯利法案(Sarbanes-Oxley Act)和PCI DSS(支付卡行业数据安全标准)监管。

虽然亚马逊选择不详细描述它是如何在令人眼花缭乱的变化速度下实现合规的，但其他人分享了他们的经验。例如，Etsy是一家手工和古着在线市场，2013年的商品销售总额超过10亿美元。该公司描述了自己是如何在实现持续部署的同时，满足PCI dss规定的职责控制隔离要求的。其“最重要的架构决策是将持卡人数据环境(CDE)与系统的其余部分分离开来，将PCI DSS法规的范围限制在一个隔离的区域，并防止它们‘泄漏’到所有生产系统。形成CDE的系统在物理、网络、源代码和逻辑基础设施级别上与Etsy的其他环境是分离的(和不同的管理)。此外，CDE由一个专门负责CDE的跨职能团队构建和运行。再一次，这将PCI DSS法规的范围限制到了这个团队。”⁴

同样重要的是要注意，职责的分离“并不妨碍跨功能CDE团队在单一空间内一起工作。当CDE团队的成员想要推动一个变更时，他们创建一个票据，由技术主管批准;否则，代码提交和部署过程是完全自动化的，就像Etsy主环境一样。没有瓶颈和延迟，因为职责的划分是局部的:变更由不同的人批准，而不是执行变更的人。”⁴

设计良好的平台即服务(PaaS)也可以在高度规范的环境中提供显著的好处。例如，在美国联邦政府中，与启动和操作信息系统相关的法律和政策长达4000多页。一个机构通常需要几个月的时间来准备文件和执行测试，以签发新系统上线所需的ATO(操作授权)。

这项工作的大部分是执行、记录和测试联邦政府风险管理框架(由国家标准与技术研究所创建和维护)所要求的控制。对于一个中等影响的系统，至少必须实施325个控制。

总务管理局(General Services Administration) 18F办公室内的一个团队的任务是通过技术改进政府为公众服务的方式，他们提出了构建PaaS的想法，以便在平台和基础设施层实现许多这些控制。gov是一个主要使用开源组件(包括Cloud Foundry)构建的PaaS，建立在亚马逊网络服务(AWS)之上。gov负责应用程序部署、服务生命周期、流量路由、日志记录、监视和警报，它还提供数据库和SSL(安全套接字层)端点终止等服务。通过将应用程序部署到cloud.gov，机构可以处理一个中等影响系统所需的325个控制中的269个，大大减少了合规负担和接收ATO所需的时间。

gov团队实践了持续交付，所有相关的源代码和配置都存储在git中，更改通过综合持续集成工具以完全自动化的方式部署。

超越网站。另一个反对持续投递的理由是，它只能应用于网站。然而，持续交付的原则和实践可以成功地应用于任何软件系统期望在其生命周期中发生实质性变化的领域。企业已经使用这些原则来开发移动应用程序和固件。

回到顶部

案例研究:惠普的固件持续交付

惠普的LaserJet固件部门为所有扫描仪、打印机和多功能设备提供固件。该团队由400人组成，分布在美国、巴西和印度。2008年，该部门出现了一个问题:它的发展速度太慢。多年来，它一直走在所有新产品发布的关键道路上，无法提供新功能:“营销人员会带着数百万个让客户眼花缭乱的想法来找我们，我们只会告诉他们，‘从你的清单中选出你想在未来612个月内得到的两样东西。’”该部门曾试图通过支出、招聘和外包来解决问题，但都没有奏效。它需要一种新的方法。

惠普LaserJet领导层设定的目标是将开发人员的生产力提高10倍，从而使固件不再是产品开发的关键路径，并降低成本。有三个高级别目标:

• 创建一个支持所有设备的单一平台。
• 增加质量，减少释放前所需的稳定量。
• 减少花在计划上的时间。

实现这些目标的一个关键因素是实现持续交付，特别注重:

• 持续整合的实践。
• 在测试自动化方面的重大投资。
• 创建硬件模拟器，以便测试可以在虚拟平台上运行。
• 在开发人员工作站上再现测试失败。

经过三年的工作，HP LaserJet固件部门通过采用连续交付、全面测试自动化、迭代和自适应的程序管理方法以及更敏捷的计划过程，改变了软件交付过程的经济性。经济效益是可观的:

• 总体开发成本降低了约40%。
• 正在开发的项目增加了大约140%。
• 每个项目的开发成本下降了78%。
• 驱动创新的资源增加了8倍。

有关该案例研究的更多信息，请参见引领变革:大规模应用敏捷和DevOps原则加里·格鲁弗和汤米·莫瑟。

从这个案例研究中要记住的最重要的一点是，只有通过团队在测试自动化和持续集成方面的大量和持续的投资，才能节省大量的成本和提高生产力。即使在今天，许多人认为精益是一种管理主导的活动，它只是关于削减成本。在现实中，它需要投资来消除浪费和减少故障需求，这是一个工人领导的活动，可以持续降低成本，提高质量和生产力。

处理遗留系统。许多组织在几十年前设计的系统(通常称为遗留系统)中保存关键任务数据。然而，持续交付的原则和实践可以在大型机系统中有效地应用。Scott Buckley和John Kordyback描述了澳大利亚最大的保险公司Suncorp是如何做到这一点的。⁴

回到顶部

案例研究:Suncorp的大型机持续交付

澳大利亚Suncorp集团有雄心勃勃的计划，包括取消其遗留的一般保险政策系统，改进其核心银行平台，并启动一个卓越运营计划。Suncorp业务系统公司时任首席执行官Matt Pancino表示:“通过淘汰重复或过时的系统，Suncorp的目标是降低运营成本，并将节省下来的成本再投资于新的数字渠道。”

精益实践和持续改进是交付简化程序的必要策略。Suncorp成功地投资于自动化测试框架，以支持快速开发、配置、维护和升级系统。使用新技术平台的人对这些技术很熟悉，尤其是在数字领域，但Suncorp成功地将敏捷和精益方法应用到大型主机系统的“大铁”世界中。

在其保险业务中，Suncorp正在将大型复杂的保险政策主机系统组合成一个系统，以支持跨组织的通用业务流程，并通过直接渠道推动更多的保险销售。一些关键部分来自“构建块”项目，它为核心大型机策略系统、敏捷交付实践和基于Web服务的系统集成的公共方法提供了功能测试框架。

在简化方案的第一年，扩大了测试范围，以支持主机政策系统与新的数字渠道和定价系统的集成。自动化验收标准是在开发不同系统时制定的。这大大缩短了将更新的定价和风险评估系统与多种保单类型集成的测试时间。自动化测试还支持通过不同渠道(如在线或呼叫中心)管理和验证客户策略。

核心功能的每晚回归测试与开发保持同步，并支持功能测试和系统到系统集成。当在端到端业务场景中发现缺陷时，响应式解决方案在数小时或数天内进行管理，而不是大型企业系统的典型数周。

在这一过程中，管理着多个不同品牌的Suncorp将15个复杂的个人和人寿保险系统减少到2个，并淘汰了12个遗留系统。技术升级一次性完成，并覆盖所有品牌。该公司为所有不同品牌和产品的面向客户的网站拥有单一的代码库。这样可以更快地响应客户需求，并使独立的团队(每个人负责一个网站)变得多余。

从业务的角度来看，更简单的系统使580个业务流程得以重新设计和精简。团队现在可以根据需求提供新的或改进的服务，而不是单独改进每个Suncorp品牌。它减少了推出新产品和服务的时间，例如为Apia品牌客户提供医疗保险，或为AAMI客户提供路边援助。

Suncorp在简化和管理核心系统方面的投资意味着该公司可以增加对所有与客户接触点的投资。在技术和商业实践方面，Suncorp加快了简化的步伐，大多数品牌现在都使用通用的基础设施、服务和流程。

Suncorp 2014年年报(http://bit.ly/2ExPnBG)指出:“精简使本集团的运作成本基础更具变数，并有能力根据市场和业务需求扩充资源和服务。”简化活动预计将在2015年和2016年分别节省2.25亿美元和2.65亿美元。

发展的人。连续交付是复杂的，需要大量的工艺和技术投资。一些经理怀疑他们的员工是否能胜任这项任务。然而，通常情况下，阻碍实现的不是员工个人的技能水平，而是管理和领导层面的失败。Netflix的云架构师阿德里安•科克罗夫特(Adrian Cockcroft)讲述了一件轶事，说明了这一点。《财富》(Fortune) 500强公司经常请他介绍Netflix转向云的情况。他们经常问他的一个问题是:“你从哪里得到Netflix的优秀员工?”他会回答:“我从你那里得到他们!”

持续交付从根本上讲就是持续改进。为了使持续改进有效，过程改进必须成为每个人日常工作的一部分，这意味着必须给予团队这样做的能力、工具和权力。经常听到经理们说，“我们想引入测试自动化，但我们没有时间，”或者“这是我们一直采用的方法，没有很好的理由去改变。”所有高绩效组织的一个共同因素是，他们总是努力变得更好，将障碍视为需要克服的挑战，而不是停止尝试的理由。

当员工被视为可替代的“资源”时，他们的角色是尽可能高效地执行分配给他们的任务，难怪他们会感到沮丧并离开。持续改进在这种环境下是无法成功的。在现代零工经济中，工人是由他们所拥有的技能来定义的，随着组织的发展和工作的变化，许多组织很少投入精力帮助员工培养新技能。相反，当某个人的技能不再必要时，这些公司就会解雇他们，然后聘用技能符合新需求的新人，然后才会奇怪为什么会出现“人才短缺”。

---

持续发布以某种方式增加风险的想法与持续发布以减少发布风险和数据的整个动机是直接矛盾的。

---

这些问题是相互关联的。一个有效的组织投资于培养员工的技能，帮助他们解决新问题，而不是解决他们被雇用时存在的问题。帮助实现这一目标的一种方法是解决问题，消除提高绩效的障碍，同时学习新的技能:这正是有效实施持续交付所需要的。

实现这一目标的障碍是组织文化，特别是领导者和管理者的行为方式。

回到顶部

克服持续交付的障碍

持续交付的原则和实践可以在各种环境中实现，从大型机到固件，再到那些高度规范的环境，但这当然不容易。例如，Amazon花了四年时间将其核心平台重新架构为支持持续交付的面向服务的体系结构。^3.通常，这种转变的最大障碍是组织文化和架构。

文化。什么是文化?埃德加·沙因，著有企业文化生存指南他将其定义为“一个群体在解决外部适应和内部融合问题时学到的一种共享的默契假设模式，这种模式运行良好，被认为是有效的，因此可以教授给新成员，作为与这些问题有关的感知、思考和感觉的正确方式。”⁶

文化的模型有很多，但有一个是罗恩·韦斯特鲁姆创造的⁷所示图1，被用来研究文化对数字系统的影响。韦斯特鲁姆的研究强调了创造一种文化的重要性，在这种文化中，新思想受到欢迎，来自整个组织的人合作追求共同目标，人们受到培训，可以带来坏消息，以便采取行动，失败和事故被视为学习如何改进的机会，而不是被视为政治迫害。

图1。Westrum的三种文化模型。

DevOps运动一直强调文化的首要重要性，特别关注开发团队和IT运营团队之间的有效协作。研究表明，开发和运维之间的双赢关系是IT性能的一个重要预测因素。DevOps运动中的实践者也使用了许多工具来帮助组织更有效地处理信息，例如ChatOps (https://www.youtube.com/watch?v=NST3u-GjjFw)、无可指责的事后分析(http://bit.ly/2C2Bud0)、全面配置管理(http://bit.ly/2EIeh0R）.

事实上，表现最好的公司不会为了学习如何改进而等到糟糕的事情发生;他们经常制造(控制)事故，以便比竞争对手更快地学习。Netflix通过“猿人军队”将这一技术提升到了一个新的高度，它不断破坏Netflix的基础设施，以不断测试其系统的弹性。

体系结构。在企业架构的上下文中，通常有多个需要关注的属性，例如，可用性、安全性、性能、可用性等等。持续交付引入了两个新的体系结构属性:可测试性和可部署性。

在一个可测试的架构，软件被设计成这样，开发人员可以(至少在原则上)通过在他们的工作站上运行自动测试来发现大多数缺陷。他们不应该依赖复杂的、集成的环境来做大部分的验收和回归测试。

在一个部署架构在美国，特定产品或服务的部署可以以完全自动化的方式独立执行，而不需要大量的编排。可部署系统通常可以在零停机或最小停机的情况下升级或重新配置。

在不优先考虑可测试性和可部署性的情况下，许多测试需要使用复杂的集成环境，而部署是“大爆炸”事件，由于复杂的相互依赖性，需要同时发布许多服务。这些大爆炸式部署需要许多团队以一种精心安排的方式一起工作，数百或数千个任务之间存在许多交接和依赖关系。这种部署通常需要数小时甚至数天，并需要安排大量停机时间。

设计可测试性和可部署性首先要确保产品和服务由松散耦合、封装良好的组件或模块组成。

一个设计良好的模块化体系结构可以定义为这样一种体系结构:在这种体系结构中，可以单独测试或部署单个组件或服务，任何依赖项都可以由合适的测试双精度对象替换，该双精度对象可以是虚拟机、存根或模拟的形式。每个组件或服务都应该以完全自动化的方式在开发人员工作站、测试环境或生产环境中进行部署。在一个设计良好的体系结构中，当以这种方式部署组件时，可以对组件是否正常运行有很高的信心。

为了帮助组件的独立部署，创建具有向后兼容性的版本化api是值得投资的。这增加了系统的复杂性，但是从部署的容易程度上获得的灵活性将会使它得到很多倍的回报。

任何真正的面向服务的体系结构都应该具有这些属性，但不幸的是，许多体系结构不具备这些属性。然而，微服务运动已经明确了这些体系结构属性的优先级。

当然，许多组织都生活在一个服务明显难以测试和部署的世界中。我们建议采用一种迭代的方法来改进企业系统的设计，而不是重新构建所有的体系结构，有时称为演进体系结构。¹在进化架构范式中，我们接受成功的产品和服务将需要在其生命周期中重新架构，因为对它们的需求不断变化。

在此上下文中特别有价值的一个模式是strangler应用程序，如所示图2．在这种模式中，通过确保按照面向服务的体系结构的原则完成新工作，同时接受新体系结构可以很好地将任务委派给它所要替换的系统，一个整体体系结构被迭代地替换为一个更组件化的体系结构。随着时间的推移，更多的功能将在新的体系结构中执行，而被取代的旧系统将被“扼杀”。(见https://www.martinfowler.com/bliki/StranglerApplication.html．)

图2。扼杀者的应用程序。

回到顶部

结论

持续交付是关于减少从版本控制到生产进行更改的风险和交易成本。实现这一目标意味着实现一系列的模式和实践，使开发人员能够创建快速的反馈循环和小批量工作。这反过来又提高了产品的质量，允许开发人员对事件和不断变化的需求做出更快速的反应，进而以更低的成本构建更稳定、更高质量的产品和服务。

如果这听起来好得令人难以置信，请记住:持续交付并不是魔法。它是指在组织的各个层面上持续的、每日的改进——追求更高绩效的持续纪律。然而，正如本文所介绍的，这些想法可以在任何领域实现;这需要在组织的所有级别进行彻底、有纪律和持续的工作。尤其困难的，尽管是必要的，是所需要的文化和架构变化。

然而，从金融科技初创公司到美国政府，各种类型和规模的组织都在实施这些想法，它们已经从特殊转变为标准。如果你还没有开始走这条路，不要担心——它是可以实现的，现在就是开始的时候。

相关文章
在queue.acm.org

微服务的隐藏红利
汤姆Killalea
https://queue.acm.org/detail.cfm?id=2956643

与Tim Marsland的对话
https://queue.acm.org/detail.cfm?id=1066063

响应型企业:拥抱黑客方式
埃里克·梅杰和维克拉姆·卡普尔
https://queue.acm.org/detail.cfm?id=2685692

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2018 ACM, Inc.

---

没有找到条目