持续集成于2000年首次使用称为Cruise Control的软件引入。多年来，持续集成已成为任何软件组织中的关键实践。这是一种开发实践，要求开发团队确保对软件程序进行的每个代码更改都进行构建和后续测试。该概念旨在消除在构建生命周期中发现问题的较晚发生的问题。取代了开发人员孤立地工作并且没有足够的集成，而是引入了持续集成以确保代码的更改和构建绝不会孤立地进行。

为什么要持续集成?

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

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

• 对于集成而言，代码是否过于复杂? –如果持续集成过程继续失败，则可能是代码太复杂了。这可能是应用适当的设计模式以使代码更简单，更易于维护的信号。

• 该代码是否符合既定的编码标准? –大多数测试用例将始终检查代码是否符合正确的编码标准。通过在自动构建之后进行自动测试，这是检查代码是否符合所有所需编码标准的好方法。

• 自动化测试涵盖了多少代码? –如果测试用例未涵盖代码所需的功能，则测试代码毫无意义。因此，确保编写的测试用例应涵盖应用程序的所有关键场景始终是一个好习惯。

• 最新更改后所有测试是否成功? –如果测试失败，则没有必要继续进行代码部署，因此这是检查代码是否已准备好移至部署阶段的好方法。

工作流程

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

因此，基于上述工作流程，通常这就是连续集成过程的工作方式。

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

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

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

• 如果该项目的构建通过，则进行单元测试。如果测试成功，则可以将代码部署到登台服务器或生产服务器。

• Continuous Integration服务器继续轮询版本控制存储库中的更改，然后重复整个过程。