持续集成 - 概述

持续集成最初于 2000 年随着名为 **Cruise Control** 的软件而引入。多年来，持续集成已成为任何软件组织的关键实践。这是一种开发实践，要求开发团队确保对软件程序进行的每次代码更改都进行构建和后续测试。这个概念旨在解决构建生命周期中后期出现问题的难题。持续集成旨在确保代码更改和构建永远不会孤立地进行，而不是让开发人员孤立地工作并且集成不足。

为什么选择持续集成？

持续集成已成为任何软件开发流程中不可或缺的一部分。持续集成流程帮助软件开发团队解答以下问题。

• 所有软件组件是否都能按预期协同工作？– 有时系统可能会变得非常复杂，每个组件都有多个接口。在这种情况下，始终至关重要地确保所有软件组件都能彼此无缝协同工作。

• 代码是否过于复杂而无法集成？– 如果持续集成流程持续失败，则可能表明代码过于复杂。这可能是一个信号，需要应用正确的设计模式来使代码更简单、更易于维护。

• 代码是否符合既定的编码标准？– 大多数测试用例始终会检查代码是否符合正确的编码标准。通过在自动化构建后进行自动化测试，这是一个检查代码是否满足所有期望的编码标准的好时机。

• 自动化测试涵盖了多少代码？– 如果测试用例没有涵盖代码所需的函数，那么测试代码毫无意义。因此，始终最佳实践是确保编写的测试用例应涵盖应用程序的所有关键场景。

• 最新更改后所有测试是否都成功？– 如果测试失败，则继续部署代码毫无意义，因此这是一个检查代码是否已准备好进入部署阶段的好时机。

工作流程

下图快速展示了整个持续集成工作流程在任何软件开发项目中的工作方式。我们将在后续章节中详细介绍。

因此，根据上述工作流程，持续集成流程通常是这样工作的。

• 首先，开发人员将代码提交到版本控制存储库。同时，集成构建机器上的持续集成服务器轮询源代码存储库以查找更改（例如，每隔几分钟）。

• 提交发生后不久，持续集成服务器检测到版本控制存储库中发生了更改，因此持续集成服务器从存储库中检索代码的最新副本，然后执行构建脚本，该脚本集成软件

• 持续集成服务器通过电子邮件将构建结果发送给指定的项目成员，从而生成反馈。

• 如果该项目的构建通过，则执行单元测试。如果测试成功，则代码即可部署到暂存服务器或生产服务器。

• 持续集成服务器继续轮询版本控制存储库中的更改，整个过程重复。