持续集成 - 要求

以下是持续集成最重要的要求列表。

• 定期签入 − 持续集成正常工作的最重要实践是频繁签入源代码存储库的主干或主线。代码签入应每天至少进行几次。定期签入带来许多其他好处。它使更改更小，从而不太可能破坏构建。这意味着当任何后续构建中出现错误时，可以知道要恢复到的最新版本的软件。

  它还有助于更自律地重构代码并坚持保留行为的小更改。它有助于确保更改大量文件的更改不太可能与其他人的工作发生冲突。它允许开发人员更具探索性，尝试新想法并通过恢复到上次提交的版本来放弃它们。

• 创建全面的自动化测试套件 − 如果您没有全面的自动化测试套件，则通过构建仅意味着可以编译和组装应用程序。虽然对于某些团队来说这是一个很大的进步，但进行一定程度的自动化测试以确保您应用程序确实在运行是必不可少的。

  通常，持续集成中进行 3 种类型的测试，即单元测试、组件测试和验收测试。

  单元测试用于单独测试应用程序小部分的行为。它们通常可以在不启动整个应用程序的情况下运行。它们不会影响数据库（如果您的应用程序有数据库）、文件系统或网络。它们不需要您的应用程序在类似生产的环境中运行。单元测试应该运行得非常快 — 您的整个套件，即使是大型应用程序，也应该能够在十分钟内运行完毕。

  组件测试测试应用程序的多个组件的行为。与单元测试一样，它们并不总是需要启动整个应用程序。但是，它们可能会访问数据库、文件系统或其他系统（可能被删除）。组件测试通常需要更长时间才能运行。

• 缩短构建和测试过程 − 如果构建代码和运行单元测试花费的时间太长，您将遇到以下问题。

  • 人们将停止进行完整构建，并在签入之前运行测试。您将开始获得更多失败的构建。

  • 持续集成过程将花费很长时间，以至于在您再次运行构建时，将发生多次提交，因此您不知道哪个签入破坏了构建。

  • 人们签入的频率会降低，因为他们必须等待很长时间才能构建软件并运行测试。

• 不要签入损坏的构建 − 持续集成的最大错误是签入损坏的构建。如果构建中断，负责的开发人员正在等待修复它。他们会尽快找出中断的原因并进行修复。如果我们采用这种策略，我们将始终处于最佳位置，可以找出导致中断的原因并立即修复它。

  如果我们的一位同事签入并因此破坏了构建，那么为了有最好的机会修复它，他们需要明确地解决问题。当这条规则被打破时，不可避免地需要更长的时间来修复构建。人们习惯于看到构建被破坏，很快你就会陷入构建一直处于破坏状态的情况。

• 提交之前始终在本地运行所有提交测试 − 始终确保在本地机器上运行为应用程序设计的测试，然后再在 CI 服务器上运行它们。这是为了确保编写了正确的测试用例，如果 CI 过程中出现任何故障，那是因为测试结果失败。

• 对因您的更改而导致的所有中断负责 −如果您提交了更改，并且您编写的所有测试都通过了，但其他测试失败了，则构建仍然失败。通常这意味着您在应用程序中引入了回归错误。由于您进行了更改，因此您有责任修复由于更改而未通过的所有测试。在 CI 的上下文中，这似乎很明显，但实际上在许多项目中这并不是一种常见的做法。