什么是持续集成？

根据 Aaron Cois 的说法，CI 是一种旨在不断地将“团队中所有开发人员的源代码更新合并到共享主线中”的技术。这种持续的合并可以防止开发人员的软件项目本地副本随着其他人添加新代码而偏离太远，从而避免灾难性的合并冲突。”

如今，集成每天至少进行一次（甚至更频繁）是常见的做法。持续集成是由 Grady Booch 创造的，然后被 Kent Beck 和极限编程 (XP) 继承和扩展。

CI 已成为 DevOps 和敏捷文化中的常见做法，并且有充分的理由：CI 可以帮助您在错误发展成重大问题之前检测和定位错误。但 CI 并不是在整个开发周期中保持代码无错误的唯一工具。

11 持续集成实践和原则

确保检查所有 11 项持续集成实践和原则以全面实施。

1. 维护单一源存储库

每个软件项目都涉及许多不同的文件，需要将这些文件集成在一起才能构建最终产品。要管理所有这些数据，您需要一个源管理工具 (SCM)，例如 Github。然后，您的所有代码都可以进入一个中央存储库。

这包括：

• 测试脚本。
• 属性文件。
• 数据库架构。
• 安装脚本。
• 第三方库。

您甚至可以放入 IDE 配置，以便人们更轻松地共享 IDE 设置。

SCM 的主要功能是允许您创建多个分支并使用主线（正在开发的项目的单个分支）管理各种开发流。持续集成是将单独的代码片段组合到主线中并对其进行测试以确保一切都能协同工作的过程。

2. 自动化构建

自动化构建意味着将您拥有的源自动转变为正在运行的系统。借助当今可用的工具，您不必手动执行此操作。此外，告诉人们键入命令并单击不同的对话框将不可避免地产生更多您首先要避免的错误。

无论您使用什么工具，它都应该分析流程中需要更改的内容。例如，Jenkins 是 DevOps 团队可用的最流行的持续集成和构建自动化工具之一。 

3. 让你的构建进行自测试

如果您想快速且频繁地捕获错误，那么您应该在构建过程中包含自动化测试。

虽然不完美，但自测试代码可以为您节省大量时间，并且在极限编程和测试驱动开发 (TDD) 爱好者中非常流行。

您希望能够对您的代码库运行一系列自动化测试，以表明它不存在任何重大缺陷。在某种程度上，如果没有自动化测试，就无法实践持续集成。虽然 XP 和 TDD 是生成自测试代码的流行方法，但您不必使用它们来创建自动化测试。

只要可以从单个命令执行测试并检查大部分代码（如果测试失败就会导致构建失败），那么您就可以开始了。

最流行的自动化测试工具之一是统一功能测试（UFT）。它配备了 API 和 Web 服务测试、持续测试、移动测试等等。自动化测试的唯一警告是，它并不能捕获所有内容。

这就是为什么要使持续集成尽可能成功，您应该严重依赖自动化测试，但也为手动测试留出空间。

4. 每个人每天都致力于主线

大多数人在讨论持续集成时想到的就是致力于主线的实践。他们应该这样做。这是整个过程的关键。

日常集成允许开发人员就他们所做的更改向其他开发人员发出警报，正是这种频繁的沟通使得更改和开发能够快速发生，而不会出现太多错误。

通常，这种做法的工作方式如下：

• 开发人员更新他们的工作副本以匹配主线。
• 他们解决与主线的冲突（如果适用）。
• 他们在本地机器上构建。
• 他们测试他们的构建。
• 如果他们通过了，他们会将其提交到主线。

经常这样做，有时一天多次，可以揭示开发人员之间的任何冲突，如果发现冲突，可以迅速修复，这意味着可以在错误出现后的几个小时内找到并修复错误。

当错误在主线中持续数周或数月时，软件项目就会比应有的时间延长数月或数年。

底线：开发人员提交到主线的频率越高，您发现的冲突错误就越少，并且修复所遇到的错误的速度就越快。

5. 每次提交都应该在集成机器上构建主线

通过使用集成机器，开发人员可以确保他们的构建成功并且准备好提交到主线。

有两种方法可以实现此目的：

1. 手动构建。
2. 持续集成服务器。

手动构建类似于您在提交到存储库之前执行的本地构建。您前往集成机器，检查主线的头部，然后开始集成构建。如果构建成功，就可以提交了。持续集成服务器（如 Jenkins）将为您监控存储库。

当对存储库的提交完成时，服务器会自动启动构建并将结果通知“提交者”。

6. 立即修复损坏的构建

如果主线构建失败，需要立即修复。这就是 CI 的要点——始终在稳定的基础上发展。现实情况是，主线构建有时会中断。没什么大不了的。

然而，这种情况不应该总是发生。如果是，则意味着其他开发人员在执行提交之前不会在本地进行构建。无论何时，修复构建都应该是每个团队成员的首要任务。快速修复构建的一种方法是恢复到主线的最新提交。然后在开发工作站上调试问题。

7. 保持快速构建

快速反馈是持续集成的标志。如果您遵循 CI 实践和原则，则构建不会花费很长时间。例如，极限编程使用 10 分钟构建。

构建速度越快，检测错误的速度就越快，并且将构建集成到主线中的速度也就越快。

8. 在生产环境的克隆中进行测试

您执行的每个测试都应该在与原始生产环境几乎匹配的环境中。

如果环境存在差异，您会得到不同且不可靠的结果。也就是说，每一个差异都存在获得实际生产中无法获得的结果的潜在风险。

这就是为什么测试环境反映生产环境至关重要，包括但不限于：

• 数据库软件。
• 操作系统。
• 图书馆。
• IP 地址和端口。
• 硬件。
• ETC。

话虽如此，但还是有明显的限制。

您不可能对最终用户桌面软件的每个变体都进行测试，以确保您的软件与其他所有软件完美交互。尽管如此，我们的目标是尽可能完美地复制环境。

9.让任何人都可以轻松获取最新的可执行文件

创建持续集成的主要原因之一是因为过去需要很长时间才能构建正确的软件。

使用像瀑布这样的老式方法，每个规范都必须提前考虑和记录。如果软件不是按照规范构建的，则很难返回并进行彻底的更改。

持续集成利用了人类的自然特征：能够发现某些事情是错误的并且需要改变。我们在这方面比提前设想所有可能的功能和设计要好得多。这就是 CI 将持续提交纳入主线的原因。

每个开发人员都应该能够运行最新的可执行文件以进行演示、探索性测试或其他任何操作。

10.每个人都能看到发生了什么

CI 如此有效的一个重要原因是它依赖于持续的沟通。确保开发人员和产品所有者之间一致沟通的方法是让每个人都能看到系统的状态以及对其所做的更改。换句话说，让任何人都可以看到主线构建。

大多数 CI 软件将允许您查看构建进度和主线构建的状态。但一些开发人员喜欢发挥创意，将连续显示连接到构建系统。这可以采取以下形式：

• 当构建成功时，灯会发出绿光；当构建失败时，灯会发出红光。
• 红色和绿色熔岩灯，其中红色灯中的气泡表明构建已经损坏太久了。
• 跳舞的兔子。
• 铃声响起。
• 等等。

您还应该确保您可以看到当前正在构建的人员以及他们所做的更改，以及更改的历史记录，以便团队中的每个人都知道项目的进展情况和进展。

11.自动化部署

持续集成需要多个环境来运行提交测试和二次测试。另外，您经常在这些环境之间移动可执行文件，有时一天多次。这应该是自动化的。

您需要的是能够将应用程序无缝部署到您选择的环境中的脚本。自动部署具有成本效益、减少错误并极大地加快进程。除了自动化部署之外，还需要自动化回滚。如果发生不好的事情（确实如此），您希望能够快速恢复到最后一个已知的稳定状态。能够回滚错误构建的额外好处是它鼓励开发人员更频繁地部署。