持续集成 - 概述

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

为什么持续集成？

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

所有软件组件是否都按其应有的方式协同工作？– 有时系统可能变得非常复杂，每个组件都有多个接口。在这种情况下，确保所有软件组件彼此无缝协作始终至关重要。
代码对于集成来说是否太复杂？– 如果持续集成过程持续失败，则可能是代码过于复杂。这可能是一个信号，要求应用适当的设计模式来降低代码的复杂性并提高可维护性。
代码是否符合既定的编码标准？– 大多数测试用例将始终检查代码是否遵循正确的编码标准。通过在自动化构建之后进行自动化测试，可以很好地检查代码是否满足所有所需的编码标准。
自动化测试覆盖了多少代码？– 如果测试用例没有涵盖代码所需的功能，那么测试代码就没有意义。因此，确保编写的测试用例涵盖应用程序的所有关键场景始终是一个很好的做法。
最新更改后所有测试都成功了吗？– 如果测试失败，则没有必要继续部署代码，因此这是检查代码是否已准备好进入部署阶段的好时机。

工作流程

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

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

首先，开发人员将代码提交到版本控制存储库。同时，集成构建机器上的持续集成服务器轮询源代码存储库的变化（例如，每隔几分钟）。
提交发生后不久，持续集成服务器检测到版本控制存储库中发生了更改，因此持续集成服务器从存储库中检索代码的最新副本，然后执行构建脚本，该脚本集成了软件
持续集成服务器通过将构建结果通过电子邮件发送给指定的项目成员来生成反馈。
如果该项目的构建通过，则进行单元测试。如果测试成功，代码就可以部署到登台或生产服务器。
持续集成服务器继续轮询版本控制存储库中的更改，并重复整个过程。