持续集成 – 概述

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

为什么要持续集成？

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

• 所有的软件组件是否按照它们应该的方式一起工作？– 有时系统会变得如此复杂，以至于每个组件都有多个接口。在这种情况下，确保所有软件组件彼此无缝工作始终至关重要。

• 代码对于集成来说是否过于复杂？– 如果持续集成过程不断失败，则代码可能过于复杂。这可能是应用适当设计模式以使代码更简单和更易于维护的信号。

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

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

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

工作流程

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

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

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

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

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

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

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