1.2.3　持续交付

著名咨询公司ThoughtWorks的咨询架构师Jez Humble把持续交付定义为：

持续交付是指以一种可持续的方式安全、快速地将所有类型的更改（包括新功能、配置更改、错误修复和实验）交付到生产环境或用户手中的能力。

——Jez Humble

计算机软件诞生半个多世纪以来，从纯粹的科学计算，到信息数据的加工处理，到大数据人工智能，再到现在的万物互联时代，软件背后所代表的人与周围世界的信息交互，其系统复杂度和应用规模已经发生了质的改变。今天有一个非常流行的词汇叫“VUCA时代”，表示当今时代显现出“从复杂到超级复杂”的特征。VUCA对应4个英语单词的首字母：易变性（volatility）、不确定性（uncertainty）、复杂性（complexity）、模糊性（ambiguity）。这4个特性也是当前云架构模式下业务系统非常鲜明的写照。为了应对软件复杂的交付过程，人们以工程化的方式试图消除软件开发过程中的不可控因素，按期交付符合目标的软件产品。软件开发方法也经历了瀑布模型开发方法、敏捷软件开发方法、DevOps软件开发模式等不同的阶段。

持续交付代表一种软件交付的能力，打通开发、测试、生产的各个环节，自动持续、增量地交付产品，以达到随时都能发布的能力，涉及一系列的开发实践方法。持续交付分为持续集成、持续部署、持续发布等阶段。

得益于云原生环境下的敏捷基础设施以及容器+镜像技术，对于开发人员所提交的每一次代码变更，通过工具（如Maven、Jenkins）触发自动编译、构建、打包成镜像，自动部署到镜像仓库，持续交付服务器会将最新的镜像文件拉取到Kubernetes集群中，并采用逐步替换容器的方式对应用进行更新，在服务不中断的前提下完成应用自动更新。整个交付过程如工厂流水线一般逐个环节往下自动触发流转，如图1-4所示。

2006年，ThoughtWorks公司的 Jez Humble、Chris Read和Dan North共同发表了一篇题为“The Deployment Production Line”（部署生产线）的文章。文中讨论了软件部署带来的生产效率问题，并首次提出了“部署生产线”模式，对如何使自动化部署活动更轻松给出了5个指导原则。

（1）Automate your deployment process：自动化部署过程，无须人工干预。

（2）Each build stage should deliver working software：每个构建阶段都应该交付可工作的软件，即对中间产物的生产（如搭建软件运行环境）不应该是一个单独的阶段。

（3）Deploy the same artifacts in every environment：在不同环境中部署同一个构件（镜像），即将应用与运行时配置分开管理。

▲图1-4　交付过程（图片来自网络）

（4）Automate testing and deployment：自动化测试和部署，即根据测试目的，分层设置几个独立的质量关卡，只有满足预期的测试结果，才会执行后续的部署过程。

（5）Evolve your production line along with the application it assembles：部署生产线也应该随着应用程序的发展而不断演进。

持续交付关注“从提交代码到产品发布”的过程，随着某个构建逐步通过每个测试阶段，代码的质量一步步得以验证，我们对它的信心也在不断提高。当然，我们在每个阶段中对环境方面的资源投入也在不断增加，即越往后的阶段，其环境与生产环境越相似。持续交付是企业（尤其互联网企业）能够快速创新、可持续发展的重要技术保证，在高质量、低成本及无风险的前提下，不断缩短产品交付周期，从而与用户频繁互动，获得及时且真实的反馈，最终创造更多客户价值的产品能力。“目标驱动，从简单问题开始，持续改进”是持续交付过程的指导思想。为了获得健康良性的持续交付效果，我们总结了4个核心工作原则。

（1）坚持少做：小步快跑一直是互联网企业保持高速发展的制胜法宝，想办法对新业务、新创意尽早验证，通过不断反馈、迭代来演进完善我们的应用系统，而不是一次性设计一个“大而全且完美”的系统。

（2）持续分解问题：复杂的业务问题中一定会包含很多不确定因素，它们会影响解决问题的速度和质量。通过对问题的层层分解，可以让团队了解业务，更早识别出关键问题和风险。

（3）坚持快速反馈：需要第一时间分析和总结对已交付产品的反馈结果，了解已完成工作的质量和效果。

（4）持续改进并衡量：任何事必须有过程、有结果，无论做了什么样的改进，如果无法以某种方式衡量它的结果，就无法证明真正得到了改进。在着手解决每个问题之前，我们都要找到恰当的衡量方式，并将其与对应的功能需求放在同等重要的位置上，一起完成。