学习测试驱动开发

第 13 章 持续集成 持续集成

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

持续集成的原则同样适用于测试，测试也应该是开发过程中的一项持续活动。

Grady Booch 等人，《面向对象分析与应用设计》（Addison-Wesley，2007 年）

通过持续集成，您的软件在每一次新的变更中都被证明是有效的（假设有一套足够全面的自动测试），而且您可以在软件出现问题时立即知道并修复它。

Jez Humble 和 David Farley，《持续交付》（Addison-Wesley，2010 年）

软件熵与热力学中的熵一样，是系统中无序程度随时间推移而增加的原理。 物理学中可能无法摆脱熵--热力学第二定律禁止这样做。有办法阻止软件中的熵吗？

目前，防止代码混乱造成破坏性影响的最佳方法是持续交付（CD）。该术语源自Agile 宣言的第一条原则，即通过 "早期持续交付有价值的软件 "来满足客户需求，并将此作为重中之重。

与之相关的一个术语是持续集成（CI），它的出现比敏捷宣言早了大约十年，由 Grady Booch 提出，并由 Kent Beck、Martin Fowler、Jez Humble、David Farley 等人加以完善。在一个拥有多名开发人员的团队中，代码的可靠集成更为重要，因此应该经常进行。¹

要实现持续集成，就必须有自动化测试。 否则，我们怎么知道新的变更是否已与现有代码 "集成"，因为再多的人工努力也无法 "持续 "测试不断增长的软件。这一点至关重要，必须着重强调。

重要

没有自动化测试，就没有持续集成。

为了从我们迄今为止编写的单元测试中获取更多价值，我们可以将其作为持续集成构建流程的一部分来运行。这可以通过多种工具来实现。在倒数第二章中，我们将使用 GitHub Actions 建立持续集成服务器。

核心概念

持续集成是软件成熟度 连续体中的第一个阶段，该阶段会发展到持续部署，最终达到持续交付。 因此，CI 是迈向持续交付的第一步。

图 13-1显示了持续集成、部署和交付（CI/CD）的总体概况。

图 13-1. 持续集成和持续部署是持续交付的演进先驱

版本控制

持续集成要求将构建软件所需的所有代码都存储在版本控制系统中。

版本控制系统至少必须提供以下功能：

1. 以任意结构和深度存储文件和文件夹的当前（最新）版本。

2. 将这些文件和文件夹存储在统一的 "存储库 "中，而不仅仅是不同的元素。

3. 存储文件和文件夹的旧版本（历史版本）--包括那些后来被删除、重命名、移动或以其他方式修改的文件和文件夹。

4. 对所有这些文件和文件夹的所有修订版本（包括当前修订版本）进行离散和按时间顺序排列的版本管理，这样就可以轻松、清晰地跟踪任何一个文件的历史版本。

5. 以确定的方式向代码库推送（提交）更改。(也就是说，应根据明确的规则接受或拒绝推送）。

6. 能够查询代码库，以检测任何新的更改。

7. 为 "推送代码"、"拉取代码 "和 "查询变更 "功能提供 CLI。

此外，这些功能也是非常可取的：

8. 在代码库中存储多个独立的分支，可以创建（分叉）、删除分支，并与其他分支重合（合并）。

9. 解决冲突的能力（当对同一文件/文件夹做出两个或多个不兼容的更改时，就会发生冲突）。 ...