持续集成 - 概述

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

为什么要进行持续集成？

持续集成已成为任何软件开发过程中非常重要的一部分。持续集成过程有助于回答软件开发团队的以下问题。

• 所有软件组件是否都按应有的方式协同工作？– 有时系统会变得非常复杂，以至于每个组件都有多个接口。在这种情况下，确保所有软件组件无缝协作始终至关重要。

• 代码是否过于复杂，无法进行集成？——如果持续集成过程持续失败，则可能是代码过于复杂。这可能是一个信号，需要应用适当的设计模式，使代码更简单、更易于维护。

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

• 自动测试涵盖了多少代码？——如果测试用例没有涵盖代码所需的功能，则测试代码毫无意义。因此，确保编写的测试用例涵盖应用程序的所有关键场景始终是一种很好的做法。

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

工作流程

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

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

• 首先，开发人员将代码提交到版本控制存储库。同时，集成构建机器上的持续集成服务器会轮询源代码存储库是否有变化（例如，每隔几分钟一次）。

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

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

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

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