持续集成 - 要求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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