3.8　它们之间是什么关系

XXX和XXX之间是什么关系？这是一个经常被问到的问题。这个问题没有明确的、无争议的答案。因为前面讲的那些潮流和运动本身，就经常没有公认的标准的定义、明确的内涵和外延，它们之间的关系也相应地变得复杂和模糊。某一项具体的实践，常常出现在不同的“学派”中。而每个“学派”又大都有天然的倾向，把自己打造成无所不包：敏捷无所不包；DevOps无所不包；持续交付也出了2.0版，无所不包……

这里给出一些相对客观、相对主流的观点。大体上来说：

• 近二十年来的各种思潮，都是基于软件工程，对软件工程的补充、纠偏和发展。

• 敏捷和精益如今经常被一起提及。

• 持续交付是持续集成的自然延伸，而持续部署是持续交付的终极“梦想”。

• 持续交付的范围和实践与DevOps的范围和实践很接近，它们都把Ops拉进来，解决部署和环境相关问题，彻底打通从开发到上线的全链路。

• 从流程范围来看，与DevOps相比，敏捷主要关注开发和测试之间的协作与融合，对部署到类生产环境进而到生产环境中的相关问题则关注较少。而精益的流程范围则比DevOps更宽，它包括软件开发全过程——既关注软件定义侧的精益创业，也关注软件从定义到开发再到发布的完整价值流的效率。

• 从关注内容来看，尽管敏捷和精益都既包括管理实践，也包括工程实践，但在实际工作中提及敏捷和精益时，经常指的是它们的管理实践，比如Scrum、看板墙等。而持续交付、DevOps更关注工程实践，比如流水线、自动化测试、自动化部署等。

• 对工具的重视程度也是不同的。在敏捷看来，“个体和互动　高于　流程和工具”，而持续交付、DevOps都很重视开发工具平台的建设，以自动化、自助化为导向。

那么，对上述这些软件开发过程及其支持工具等方面的探索，与容器、微服务等软件架构和技术方面的演进，又是什么关系呢？它们是相互成就的关系。例如，如果没有以流水线为代表的流程自动化，那么当将应用拆分成多个微服务时，不论是测试还是发布都很麻烦。而在反方向上，容器化使得新建一个测试环境变得便宜和容易，于是可以有更多的测试环境，让开发人员尽早进行测试，尽早发现和修复问题，而不用等到集成后再部署到测试环境中，由测试人员进行测试。

最后，本书和这些“流派”之间是什么关系呢？本书不是要开创一个新的“流派”。本书聚焦于软件交付过程这个领域（或者说这个学科），努力把它成体系地讲清楚、讲明白。如果将来有了新的“流派”，那么本书的未来版本大概也会把它吸纳进来。

在实际项目中，我们要面对软件交付过程这个领域，结合具体情况，取“百家之长”，综合运用。本书介绍“百家之长”，讲解如何综合运用。

[1]来源：链接2。

[2]来源：链接3。

[3]这个故事来自《精益思想》一书的第2章“价值流”。

[4]资源效率、流动效率的概念详见《精益产品开发：原则、方法与实施》一书的第2章“精益产品开发的核心原则（上）：聚焦价值流动效率”。

[5]译文：链接4；原文：链接5。

[6]除了构建、单元测试、代码扫描，持续集成也涉及部署到测试环境并测试，但考虑到持续交付也会涉及这部分内容，所以我们将其放到“持续交付”部分来讲。

[7]来源：链接6。

[8]来源：链接7。

[9]来源：链接8。

[10]参见《DevOps实践指南》一书。

[11]来源：链接9。注意，原文位于境外网站上。