PDF持续交付听起来很棒，但它在这里适用吗？
这不是魔法，它只是需要在各个层面持续进行日常改进。
Jez Humble
持续交付是一系列原则、模式和实践的集合，旨在使部署——无论是大规模分布式系统、复杂的生产环境、嵌入式系统还是移动应用程序——变得可预测、例行公事，并且可以在任何时间按需执行。本文介绍了持续交付，提出了实施它的常见反对意见和实际障碍，并描述了如何使用真实案例来克服它们。
什么是持续交付？
持续交付的目标是能够以可持续的方式安全、快速地将所有类型的变更（包括新功能、配置更改、错误修复和实验）部署到生产环境或用户手中。
人们通常认为，更频繁地部署软件意味着系统稳定性和可靠性会降低。事实上，同行评审的研究表明，情况并非如此；高性能团队始终比低性能竞争对手更快、更可靠地交付服务。即使在金融服务和政府等高度监管的领域也是如此。
对于愿意投入精力追求它的组织而言，这种能力提供了竞争优势。它使团队能够在准备就绪时交付新功能，与真实客户测试可行的原型，并构建和发展更稳定、更具弹性的系统。实施持续交付也被证明可以降低产品和服务不断发展的持续成本，提高其质量，并减少团队倦怠。
虽然持续部署（持续发布软件的每个良好构建版本的实践）主要限于云或数据中心托管的服务，但持续交付——此处描述的实现持续部署的一系列实践——可以应用于任何领域。
许多原则和实践构成了持续交付的规范（在 https://continuousdelivery.com 上了解更多信息）。
对持续交付的常见反对意见
虽然人们可能了解持续交付，但他们通常认为“它在这里行不通”。最常见的反对意见如下：
• 在高度监管的环境中工作时，持续交付是不合适的。
• 持续交付仅适用于网站。
• 持续交付实践不能应用于遗留系统。
• 持续交付需要的工程师比这里可用的工程师更有经验和才能。
在本节中，我们将审查并驳斥这些说法，然后讨论实施持续交付的真正障碍：不充分的架构和非生成型文化。
在高度监管的环境中工作
对在监管环境中使用持续交付的反对意见通常有两种类型：首先，持续交付在某种程度上“风险更高”的毫无根据的看法；其次，许多法规的编写方式不易与持续交付的实践相协调。
持续交付会增加风险的想法与持续交付的整个动机（降低发布风险）和数据直接矛盾。四年的数据 表明，高性能团队实现了高吞吐量和高稳定性。2 这是可能的，因为持续交付核心实践——全面的配置管理、持续测试和持续集成——允许快速发现代码中的缺陷、环境中的配置问题以及部署过程中的问题。
在持续交付中，对类生产环境的自动化部署在整个部署管道中频繁执行，并且针对如此部署的构建版本运行全面的自动化测试，从而提高了对正在构建的软件既可部署又适合用途的信心。
相比之下，许多组织采用风险缓解策略，实际上相当于表演：无休止的电子表格、清单和会议，其目的更多是为了确保流程得到遵循，而不是真正减少部署过程的痛苦和风险。所有这些并不是说更传统的风险管理流程在做得好的情况下不能奏效。相反，这表明持续交付提供了一种替代的风险管理策略，该策略已被证明至少与传统策略一样有效，同时还能够实现更频繁的发布。
持续交付与常见的监管制度相悖的想法也值得更仔细地审视。关于实施旨在实现监管目标的控制措施的大部分指南都假设发布频率较低，并且采用完整的功能筒仓的传统分阶段软件交付生命周期。然而，通常也可以在持续范式中实现控制目标。亚马逊就是一个例子，它在 2011 年平均每 11.6 秒向生产环境发布一次变更，一小时内最多部署 1,079 次（汇总了亚马逊的生产环境）。5 作为一家处理大量信用卡交易的上市公司，亚马逊同时受到监管会计实务的萨班斯-奥克斯利法案和 PCI DSS（支付卡行业数据安全标准）的约束。
虽然亚马逊选择不详细描述它如何在如此惊人的变更速度下实现合规性，但其他人分享了他们的经验。例如，Etsy 是一家在线手工和复古市场，2013 年商品销售总额超过 10 亿美元，它描述了如何在实践持续部署的同时满足 PCI DSS 强制要求的职责分离控制。其“最重要的架构决策是将持卡人数据环境 (CDE) 与系统的其余部分分离，将 PCI DSS 法规的范围限制在一个隔离区域，并防止它们‘泄漏’到所有生产系统中。构成 CDE 的系统在物理、网络、源代码和逻辑基础设施级别上与 Etsy 环境的其余部分隔离（并以不同的方式管理）。此外，CDE 由一个跨职能团队构建和运营，该团队专门负责 CDE。同样，这会将 PCI DSS 法规的范围限制在该团队。”4
同样重要的是要注意，职责分离“不会阻止跨职能 CDE 团队在同一空间中协同工作。当 CDE 团队的成员想要推送变更时，他们会创建一个工单，由技术主管批准；否则，代码提交和部署过程将像主 Etsy 环境一样完全自动化。没有瓶颈和延迟，因为职责分离保持在本地：变更由与执行变更的人员不同的其他人批准。”4
精心设计的平台即服务 (PaaS) 也可以在高度监管的环境中提供显著的优势。例如，在美国联邦政府中，与启动和运营信息系统相关的法律和政策超过 4,000 页。一个机构通常需要几个月的时间来准备文档并执行颁发新系统上线所需的 ATO（运行授权）所需的测试。
这项工作的大部分内容是实施、记录和测试联邦政府风险管理框架（由国家标准与技术研究院创建和维护）要求的控制措施。对于中等影响系统，至少必须实施 325 项控制措施。
通用服务管理局 18F 办公室（其使命是通过技术改进政府服务公众的方式）内的一个团队提出了构建 PaaS 的想法，以在平台和基础设施层实施许多这些控制措施。Cloud.gov 是一个 PaaS，主要使用开源组件构建，包括 Cloud Foundry，基于 AWS（亚马逊网络服务）之上。Cloud.gov 负责应用程序部署、服务生命周期、流量路由、日志记录、监控和警报，并提供数据库和 SSL（安全套接字层）端点终止等服务。通过将应用程序部署到 cloud.gov，各机构可以处理中等影响系统要求的 325 项控制措施中的 269 项，从而大大减轻合规性负担和获得 ATO 所需的时间。
cloud.gov 团队实践持续交付，所有相关的源代码和配置都存储在 git 中，并且通过 concourse 持续集成工具以完全自动化的方式部署变更。
超越网站
对持续交付的另一个反对意见是，它只能应用于网站。然而，持续交付的原则和实践可以成功地应用于任何软件系统在其生命周期中预期会发生重大变化的领域。组织已经采用这些原则构建移动应用程序和固件。
案例研究：惠普固件的持续交付
惠普 LaserJet 固件部门构建运行其所有扫描仪、打印机和多功能设备的固件。该团队由分布在美国、巴西和印度的 400 人组成。2008 年，该部门遇到了一个问题：它行动太慢了。多年来，它一直处于所有新产品发布的关键路径上，并且无法交付新功能：“市场营销部门会向我们提出数百万个让客户眼花缭乱的想法，而我们只会告诉他们，‘从你的列表中，选择你希望在未来 6-12 个月内获得的两件事。’”该部门曾尝试通过花费、招聘和外包来摆脱困境，但没有任何效果。它需要一种全新的方法。
惠普 LaserJet 领导层设定的目标是将开发人员的生产力提高 10 倍，以便将固件从产品开发的关键路径上移除并降低成本。有三个高层次目标：
• 创建一个支持所有设备的单一平台。
• 提高质量并减少发布前所需的稳定化量。
• 减少花在计划上的时间。
实现这些目标的关键要素是实施持续交付，特别关注：
• 持续集成的实践。
• 对测试自动化的大量投资。
• 创建硬件模拟器，以便可以在虚拟平台上运行测试。
• 在开发人员工作站上重现测试失败。
经过三年的努力，惠普 LaserJet 固件部门通过采用持续交付、全面的测试自动化、迭代和适应性强的项目管理方法以及更敏捷的计划流程，改变了软件交付过程的经济性。经济效益显著：
• 总体开发成本降低了约 40%。
• 开发中的项目增加了约 140%。
• 每个项目的开发成本下降了 78%。
• 推动创新的资源增加了八倍。
有关此案例研究的更多信息，请参阅 Gary Gruver 和 Tommy Mouser 的著作《引领转型：大规模应用敏捷和 DevOps 原则》。
从本案例研究中要记住的最重要一点是，巨大的成本节省和生产力提高只有在团队对测试自动化和持续集成进行大量且持续的投资的情况下才有可能实现。即使在今天，许多人仍然认为精益是一种管理层主导的活动，并且仅仅是关于削减成本。实际上，它需要投资来消除浪费和减少失败需求——这是一项以工人为主导的活动，可以不断降低成本并提高质量和生产力。
处理遗留系统
许多组织将关键任务数据保存在几十年前设计的系统中，这些系统通常被称为遗留系统。然而，持续交付的原则和实践可以在大型机系统的背景下有效地应用。Scott Buckley 和 John Kordyback 描述了澳大利亚最大的保险公司 Suncorp 正是这样做的。
案例研究：Suncorp 大型机的持续交付
澳大利亚 Suncorp 集团制定了雄心勃勃的计划，以停用其遗留的一般保险保单系统，改进其核心银行平台，并启动卓越运营计划。“通过停用重复或过时的系统，Suncorp 旨在降低运营成本，并将这些节省下来的资金再投资于新的数字渠道，”时任 Suncorp 业务系统首席执行官 Matt Pancino 说。
精益实践和持续改进是交付简化计划的必要策略。Suncorp 正在成功投资自动化测试框架，以支持快速开发、配置、维护和升级系统。这些技术对于使用新技术平台的人员来说很熟悉，尤其是在数字领域，但 Suncorp 正在成功地将敏捷和精益方法应用于大型机系统的“大型钢铁”世界。
在其保险业务中，Suncorp 正在将大型且复杂的保险保单大型机系统合并为一个系统，以支持整个组织的通用业务流程，并通过直销渠道推动更多保险销售。一些关键部分来自“构建模块”计划，该计划为核心大型机保单系统、敏捷交付实践以及基于 Web 服务的通用系统集成方法提供了功能测试框架。
在简化计划的第一年，测试范围扩大到支持大型机保单系统与新的数字渠道和定价系统的集成。在不同系统开发的同时，开发了自动化验收标准。这大大减少了将较新的定价和风险评估系统与多种保单类型集成所需的测试时间。自动化测试还支持通过不同渠道（例如在线或呼叫中心）管理和验证客户保单。
核心功能的夜间回归测试与开发保持同步，并支持功能测试和系统到系统集成。当在端到端业务场景中发现缺陷时，响应式解决方案会在数小时或数天内得到管理，而不是大型企业系统典型的数周。
在此过程中，监管着多个不同品牌的 Suncorp 已将 15 个复杂的人寿和人寿保险系统减少到 2 个，并停用了 12 个遗留系统。技术升级一次完成，并在所有品牌中推广。该公司为其所有不同品牌和产品的面向客户的网站使用单一代码库。这可以更快地响应客户需求，并使每个负责一个网站的独立团队变得多余。
从业务角度来看，更简单的系统允许 580 个业务流程被重新设计和简化。团队现在可以根据需求提供新的或改进的服务，而不是孤立地改进每个 Suncorp 品牌。它缩短了推出新产品和服务的时间，例如 Apia 品牌客户的健康保险或 AAMI 客户的道路救援。
对 Suncorp 核心系统的简化和管理的投资意味着该公司可以增加对其所有客户接触点的投资。在技术和业务实践方面，Suncorp 加快了简化步伐，大多数品牌现在都使用通用基础设施、服务和流程。
Suncorp 的 2014 年年度报告 指出，“简化使集团能够运营更可变的成本基础，能够根据市场和业务需求调整资源和服务规模。”简化活动预计将在 2015 年实现 2.25 亿美元的节省，并在 2016 年实现 2.65 亿美元的节省。
培养人才
持续交付很复杂，需要大量的流程和技术投资。一些管理者想知道他们的员工是否能够胜任这项任务。然而，通常情况下，阻碍实施的不是员工个人的技能水平，而是管理和领导层面的失败。Netflix 前云架构师 Adrian Cockcroft 的一个轶事说明了这一点，财富 500 强公司经常请他介绍 Netflix 向云的迁移。他们经常问他的一个问题是，“你们从哪里获得 Netflix 的优秀员工？”他会回答，“我从你们那里获得他们！”
持续交付从根本上说是关于持续改进的。为了使持续改进有效，流程改进必须成为每个人日常工作的一部分，这意味着必须为团队提供能力、工具和权力来做到这一点。经常听到管理者说，“我们很乐意引入测试自动化，但我们没有时间”，或者“我们一直都是这样做的，没有充分的理由改变”。所有高性能组织的共同因素是，他们始终努力变得更好，并且将障碍视为需要克服的挑战，而不是停止尝试的理由。
当工人被视为可替代的“资源”，其角色是尽可能高效地执行分配给他们的任务时，难怪他们会感到沮丧并退出。在这种类型的环境中，持续改进不可能成功。在现代零工经济中，工人由他们拥有的技能组合来定义，许多组织很少努力投资于帮助他们的工人发展新技能，因为组织不断发展，工作不断变化。相反，这些公司在他们的技能不再必要时解雇员工，并雇用技能符合新需求的新员工，然后想知道为什么会出现“人才短缺”。
这些问题是相关的。一个有效的组织投资于培养员工的技能来帮助解决新问题，而不是他们受雇时存在的问题。帮助实现这一目标的一种方法是通过解决问题来消除提高绩效的障碍，在此过程中学习新技能：这正是有效实施持续交付所需要的。
实现这一目标的障碍是组织文化，特别是领导者和管理者的行为方式。
克服持续交付的障碍
持续交付的原则和实践可以在各种环境中实施，从大型机到固件，再到高度监管的环境，但这当然不容易。例如，亚马逊花了四年时间 将其核心平台重新架构为支持持续交付的面向服务的架构。3 通常，这种转型的最大障碍是组织文化和架构。
文化
什么是文化？《企业文化生存指南》的作者 Edgar Schein 将其定义为“一个群体在解决其外部适应和内部整合问题时学到的一系列共享的默认假设，这些假设运作良好，被认为是有效的，因此，被教给新成员，作为在与这些问题相关时感知、思考和感受的正确方式。”6
文化有很多模型，但 Ron Westrum7 创建的一个模型（如图 1 所示）已被用于研究文化对数字系统的影响。Westrum 的研究强调了创建一种文化的重要性，在这种文化中，新想法受到欢迎，来自整个组织的人们为追求共同目标而协作，人们接受培训以带来坏消息以便可以采取行动，并且将失败和事故视为学习如何改进的机会，而不是视为政治迫害。
DevOps 运动始终强调文化的首要重要性，特别关注开发团队和 IT 运营团队之间的有效协作。研究表明，开发和运营之间双赢的关系是 IT 绩效的重要预测指标。DevOps 运动的实践者还使用了许多工具来帮助组织更有效地处理信息，例如 ChatOps、无责事后分析 和 全面的配置管理。
事实上，绩效最高的公司不会等到坏事发生才学习如何改进；他们会定期制造（受控的）事故，以便比竞争对手更快地学习。Netflix 通过 Simian Army 将此提升到一个新的水平，Simian Army 不断破坏 Netflix 基础设施，以便持续测试其系统的弹性。
架构
在企业架构的背景下，通常有多个属性需要关注——例如，可用性、安全性、性能、可用性等等。持续交付引入了两个新的架构属性：可测试性和可部署性。
在可测试架构中，软件的设计使得开发人员（原则上至少）可以通过在其工作站上运行自动化测试来发现大多数缺陷。他们不应该依赖复杂的集成环境来进行大多数验收和回归测试。
在可部署架构中，特定产品或服务的部署可以独立且以完全自动化的方式执行，而无需大量编排。可部署系统通常可以在零或最短停机时间内升级或重新配置。
在可测试性和可部署性未得到优先考虑的情况下，许多测试需要使用复杂的集成环境，并且部署是“大爆炸”事件，由于复杂的相互依赖性，需要同时发布许多服务。这些大爆炸部署需要许多团队以精心协调的方式协同工作，在数百甚至数千个任务之间进行许多交接和依赖。此类部署通常需要数小时甚至数天，并且需要安排大量停机时间。
为可测试性和可部署性而设计始于确保产品和服务由松散耦合、良好封装的组件或模块组成。
精心设计的模块化架构可以定义为可以单独测试或部署单个组件或服务的架构，任何依赖项都由合适的测试替身替换，测试替身可以是虚拟机、存根或模拟。每个组件或服务都应以完全自动化的方式部署在开发人员工作站、测试环境或生产环境中。在精心设计的架构中，可以高度确信组件以这种方式部署时运行正常。
为了帮助组件的独立部署，创建具有向后兼容性的版本化 API 值得投资。这增加了系统的复杂性，但易于部署方面的灵活性收益将远远超过其成本。
任何真正的面向服务的架构都应具有这些属性——但不幸的是，许多架构都没有。然而，微服务运动已将这些架构属性明确地作为优先事项。
当然，许多组织生活在一个服务明显难以测试和部署的世界中。我们建议采用迭代方法来改进企业系统的设计，而不是重新架构所有内容，有时称为进化架构。1 在进化架构范式中，我们接受成功的产品和服务在其生命周期中将需要重新架构，因为对它们的要求不断变化。
在这种情况下特别有价值的一种模式是绞杀者应用程序，如图 2 所示。在这种模式中，通过确保新工作遵循面向服务的架构原则来迭代地替换单体架构，同时接受新架构很可能会将任务委派给它正在替换的系统。随着时间的推移，越来越多的功能将在新架构中执行，而被替换的旧系统将被“绞杀”。（参见 https://martinfowler.com.cn/bliki/StranglerApplication.html。）
结论
持续交付是关于降低将变更从版本控制到生产环境的风险和交易成本。实现此目标意味着实施一系列模式和实践，使开发人员能够创建快速反馈循环并以小批量工作。反过来，这提高了产品质量，使开发人员能够更快地响应事件和不断变化的需求，并反过来以更低的成本构建更稳定和更高质量的产品和服务。
如果这听起来好得令人难以置信，请记住：持续交付不是魔法。它是关于组织各个层面持续的日常改进——不断追求更高绩效的纪律。然而，正如本文所介绍的，这些想法可以在任何领域实施；这需要在组织各个层面进行彻底、严谨和持续的工作。尤其困难但至关重要的是所需的文化和架构变革。
然而，随着从金融科技初创公司到美国政府的各种类型和规模的组织实施这些想法，它们已从例外情况转变为标准。如果您尚未开始这条道路，请不要担心——这是可以实现的，现在是开始的时候了。
参考文献
1. Ford, N., Parsons, R., Kua, P. 2017. 构建进化架构：支持持续变更。O'Reilly Media; (http://evolutionaryarchitecture.com).
2. Forsgren, N., et al. 2014-2017. DevOps 状态报告。Puppet 和 DevOps Research and Assessment LLC; (https://devops-research.com/research.html).
3. Gray, J. 2006. 与 Werner Vogels 的对话。acmqueue 4(4); https://queue.org.cn/detail.cfm?id=1142065.
4. Humble, J., O'Reilly, B., Molesky, J. 2014. 精益企业：高性能组织如何大规模创新。O'Reilly Media. 242-243.
5. Jenkins, J. 2011. Velocity 文化（运营中未满足的挑战）。O'Reilly Velocity 大会; http://assets.en.oreilly.com/1/event/60/Velocity%20Culture%20Presentation.pdf .
6. Schein, E. 1999. 企业文化生存指南。Jossey-Bass.
7. Westrum, R. 2004. 组织结构类型学。BMJ 质量与安全 13(2); http://qualitysafety.bmj.com/content/13/suppl_2/ii22 .
相关文章
微服务的隐藏红利 Tom Killalea
微服务并非适用于每家公司，而且过程并不容易。
https://queue.org.cn/detail.cfm?id=2956643
与 Tim Marsland 的对话
将软件交付提升到新的水平
https://queue.org.cn/detail.cfm?id=1066063
响应式企业：拥抱黑客之道
Erik Meijer 和 Vikram Kapoor
很快每家公司都将成为软件公司。
https://queue.org.cn/detail.cfm?id=2685692
Jez Humble 是 DevOps 手册、精益企业 和 Jolt 获奖作品 持续交付 的合著者。在他的职业生涯中，他一直在三大洲不同规模的公司中尝试代码、基础设施和产品开发，最近在美国政府 18f 办公室工作。他目前在他的初创公司 DevOps Research and Assessment LLC 研究如何构建高性能团队，并在 加州大学伯克利分校任教。
版权 © 2017 由所有者/作者持有。出版权已授权给 。
最初发表于 Queue vol. 15, no. 6—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非密码哈希函数的标准
尽管密码哈希函数和非密码哈希函数无处不在，但在它们的设计方式上似乎存在差距。存在许多由各种安全要求驱动的密码哈希标准，但在非密码方面，存在一定的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布非常有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 行动
DevEx（开发者体验）在许多软件组织中越来越受到关注，因为领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付。直观地看，技术领导者普遍接受良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，为改进 DevEx 而提出的倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过介绍使用基于代码、低代码和极端低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在其快速前进的匆忙中，它容易受到时尚潮流的影响，并且可能会忘记或忽略某些长期存在的问题的成熟解决方案。用例于 1986 年首次引入，后来被普及，是这些成熟的解决方案之一。
© 保留所有权利。