第1章 持续交付2.0 @20210304

经典图书《持续交付》已出版8年，一直受到软件行业从业者的关注。书中的软件开发原则和实践也随着商业环境「VUCA特性」的明显增强而逐渐受到软件技术人员的认可。

VUCA -EvolatilityB是 uncertainty（不确定性）、 complexity（复杂性）和Ambiguity（模糊性）的首字母缩写。VUCA这个术语源于军事用语，在20世纪90年代开始被普遍使用，用来描述冷战结束后的越发不稳定的、不确定的、复杂、模棱两可和多边的世界。在2001年9月11日恐怖袭击发生之后，这一概念和首字母缩写才真正被确定。随后，UCA被战略性商业领袖们用来描述已成为“新常态”的、混乱的和快速变化的商业环境。

然而，在应用这些为达成持续交付目标所需的软件技术相关原则与实践时，我们会遇到很多难题。例如，

	业务压力太大，没有时间改进；

	开发和测试的时间被压缩得太少了，没有时间这么干；

	这么做的风险太高了，质量很难保障。

而这些难题正是由于软件工程的发展惯性带来的，是到了改变的时候了。

1.1　软件工程发展概述 1

“软件工程”这一学科出现于1968年，当时正值第一次软件危机：

	落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

人们试图借鉴「建筑工程领域」的工程方法，来解决这一问题，以实现“按预算，准时交付所需功能的软件项目”的愿望。

1.1.1　瀑布软件开发方法 1

「瀑布软件开发模型」由Dr r. Winston Rovce在1970年发表的“Managing the development of large software systems”一文中首次提出。

它将软件开发过程定义为多个阶段，每个阶段均有严格的输入和输出标准，项目理者希望通过这种重计划、重流程、重文档的方式来解决软件危机。

	需求分析 -> 软件需求 -> 分析 -> 程序设计 -> 编码 -> 测试 -> 部署

很多人将具有以上个特征的软件开发方法统称为“重型软件开发方法”。

在20世纪，瀑布软件开发模型的每个阶段都需要花费数月的时间。在写出第一行产品代码之前，甲乙双方需要花费大量精力确定需求范围，审核比《新华字典》厚得多的软件需求规格说明书。即便如此，双方还是要为“是否发生了需求范围的变更”“是否准时交付了软件”“交付的软件是否满足了预先设定的业务需求”而纠缠不清。

1.1.2　敏捷软件开发方法 2

2001年，17位软件大师齐聚加拿大的一个小镇雪鸟（Snowbird），总结了当时涌现的这些轻量级软件开发方法所具备的特点，共同发表了「敏捷宣言」，提出敏捷软件开发方法应该遵循的十二原则：

	* 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
	* 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
	* 经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
	* 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
	* 围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
	* 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
	* 敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
	* 不断地关注优秀的技能和好的设计会增强敏捷能力。
	* 简单----使未完成的工作最大化的艺术----是根本的。
	* 最好的构架、需求和设计出自与自组织的团队。
	* 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

凡符合这一宣言所倡导的价值观且遵循十二开发原则的方法均可被认为是「敏捷软件开发方法」。因此，「敏捷软件开发方法」这一说法从其诞生开始就是「一簇软件开发方法」的代名词，而不是特指某一种软件开发方法。

敏捷软件开发方法强调发挥人的主观能动性提倡面对面沟通、拥抱变化、通过迭代、增量开发尽早交付有价值的软件。

一个软件交付计划被划分成多个迭代，强调在每个迭代结束时应该得到可运行的软件。

「持续集成」作为敏捷开发方法中的一个工程实践，率先被更广泛的IT组织所接受，即便那些没有采纳敏捷开发方法的团队也会使用它，因为其强调的频繁自动化构建和自动化测试减少了质量保障团队的重复工作量，也排除了开发团队与质量保障团队之间的沟通障碍。

虽然敏捷开发方法使用的是迭代模型，但两次软件发布之间的间隔时间仍旧较长（通常是数月，甚至一年以上）。

	因此，业务人员与研发团队之间关于需求变更和研发效率的矛盾仍旧是主要矛盾。

	系统的部署发布工作在整个发布周期中所占用的时间和成本相对较小，部署和运维工作还不是突出矛盾。

	另外，部署活动通常由专门的技术运维团队执行，产品研发团队对其无感。

在这一时期，无论瀑布开发还是敏捷开发，在软件行业中最重要的关注点都是「可交付的软件包本身」，即如何快速地将软件需求变为可交付的软件包。

1.1.3　DevOps运动 3

截止到2017年，其定义为:

	DevOps是一种软件工程文化和实践，旨在统一整合软件开发和软件运维。 DevOps运动的主要特点是**强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进行全面的自动化和监控**。 DevOpst的目标是缩短开发周期，提高部署频率和更可靠地发布，与业务目标保持一致。

业界对 DevOps并没有统一的标准定义。正如“敏捷”一样，每一位从业者、每一个企业都有自己所理解的DevOps。

DevOps并非一个标准、一种模式或者一套固定方法，而是一种IT组织管理的发展趋势，也就是说，通过多种方式打破IT职能部门之间的隔阂，改变IT组织内部的原有合作模式，使之更紧密结合，从而促进业务迭代速度更快。这种发展趋势将会引起IT组织内部原有角色与分工的变化，甚至范围更大，会影响到相关的业务组织。对互联网公司来说，其软件产品对业务发展起到极其关键的作用，业务结果与IT效能强关联，因此顺应这一发展趋势的动力更加明显和迫切。

既然DevOps是一种组织管理的发展趋势，那么它就是IT领域普适的。对于不同行业、不同企业中的IT组织，需要根据其所在行业的行业特点以及企业实际状况进行一系列的管理定制。

1.1.4　持续交付1.0

2006年，“The Deployment Production Line”（部署生产线）的文章。文中讨论了软件部署带来的生产效率问题，并首次提出“部署生产线”模式，并提出了四条知道原则：

		（1）每个构建阶段都应该交付可工作的软件，即对于中间产物的生成（例如搭建软件框架）不应该是一个单独的阶段。
		（2）用同一个制品（artifacts）向不同类型的环境部署，即将其与运行时配置分开管理。（“一次构建，多次使用”）
		（3）自动化测试和部署，即根据测试目的，分成几个独立的质量关卡。
		（4）这个部署生产线设计也应该随着你的应用程序的发展而不断演进。

提交测试关卡 -> 验收测试关卡 -> 性能测试关卡 -> 生产环境部署

Jez Humbles说:持续交付是一种能力，也就是说，能够以可持续方式，安全快速地把代码变更（包括特性、配置、缺陷和试验）部署到生产环境上，让用户使用。”

1.2　持续交付2.0 7

对持续交付1.0的升级。

1.2.1　精益思想 8

1.2.2　双环模型 9

1.2.3　4个核心原则 11

1.2.4　持续交付七巧板 12

1.3　小结 13

相关文章

「08」- 利于集成的分支策略
「第5章」- 持续交付的软件系统架构
第12章　低风险发布
「07」- 部署流水线原则与工具设计