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

• 定期检入-要使连续集成正常工作，最重要的做法是经常检入源代码存储库的主干或主干。每天至少要签入两次代码。定期检查会带来很多其他好处。它使更改更小，因此不太可能破坏构建。这意味着在后续的任何构建中出错时，都会知道要还原到的最新软件版本。

  它还有助于使人们对重构代码更有纪律，并坚持一些小的改动以保留行为。它有助于确保更改大量文件的更改与其他人的工作冲突的可能性较小。它可以使开发人员更具探索性，可以尝试想法并通过还原到最后提交的版本来丢弃它们。

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

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

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

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

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

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

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

  • 人们将减少签入的次数，因为他们不得不等待很长时间才能等待软件的构建和测试的运行。

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

  如果我们的一位同事进行了检入并因此破坏了构建，那么为了最大程度地修复它，他们将需要对问题进行明确的处理。违反此规则后，修复该构建将不可避免地花费更长的时间。人们习惯于看到构建已损坏，然后很快您就会陷入构建一直处于损坏状态的情况。

• 始终在提交之前在本地运行所有提交测试-始终确保为应用程序设计的测试先在本地计算机上运行，然后再在CI服务器上运行它们。这是为了确保编写正确的测试用例，并且如果CI流程中有任何失败，则是由于失败的测试结果所致。

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