持续集成 – 需求

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

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

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

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

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

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

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

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

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

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

  • 人们将减少签入的频率，因为他们必须长时间等待软件构建和测试运行。

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

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

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

• 对因更改而导致的所有损坏负责– 如果您提交了更改并且您编写的所有测试都通过了，但其他测试失败了，则构建仍然被破坏。通常这意味着您在应用程序中引入了回归错误。您有责任（因为您进行了更改）修复所有因更改而未通过的测试。在 CI 的上下文中，这似乎是显而易见的，但实际上这在许多项目中并不常见。