持续集成 - 需求

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

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

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

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

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

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

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

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

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

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

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

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

  如果我们的同事进行了签入，结果破坏了构建，那么为了最大限度地修复它，他们将需要清晰地解决问题。当违反此规则时，构建的修复时间不可避免地会长得多。人们习惯于看到构建中断，很快您就会陷入构建始终中断的情况。

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

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