以下是持续集成的最重要要求列表.
定期办理登机手续 : 持续集成以正常工作的最重要实践是频繁签入源代码存储库的主干或主线.代码的签到应该每天至少发生几次.定期办理登机手续会带来许多其他好处.它使更改变小，从而不太可能破坏构建.这意味着当任何后续构建中出现错误时，最近恢复的大多数软件都是已知的.
它还有助于在重构代码和遵守小代码方面更加自律保持行为的变化.它有助于确保更改大量文件的更改不太可能与其他人的工作冲突.它允许开发人员更具探索性，尝试想法并通过恢复到最后提交的版本来丢弃它们.
创建全面的自动化测试套件 : 如果您没有全面的自动化测试套件，则传递构建仅意味着可以编译和组装应用程序.虽然对于某些团队来说这是一个很大的进步，但必须进行一定程度的自动化测试，以确保您的应用程序实际正在运行.
通常，有3种类型的测试在持续集成即单元测试，组件测试和验收测试.
单元测试用于测试小块的行为你的申请是孤立的.它们通常可以在不启动整个应用程序的情况下运行它们不会访问数据库(如果您的应用程序有)，文件系统或网络.它们不要求您的应用程序在类似生产环境中运行.单元测试应该运行得非常快 - 整个套件，即使对于大型应用程序，也应该能够在十分钟内运行.
组件测试测试应用程序的几个组件的行为.与单元测试一样，它们并不总是需要启动整个应用程序.但是，它们可能会访问数据库，文件系统或其他系统(可能会被删除).组件测试通常需要更长时间才能运行.
保持构建和测试流程简短 : 如果构建代码并运行单元测试需要很长时间，则会遇到以下问题:
People将停止进行完整构建，并在签入之前运行测试.您将开始获得更多失败的构建.
持续集成过程将花费很长时间，以至于在运行构建时会发生多次提交再次，所以你不知道哪个登记入住打破了建设.
人们将不经常办理登机手续，因为他们必须等待很长时间等待用于构建软件和运行测试.
Don' t在破损的建筑物上办理登机手续 : 持续集成的最大错误是检查破坏的构建.如果构建中断，负责的开发人员正在等待修复它.他们尽快确定破损的原因并加以修复.如果我们采用这种策略，我们将始终处于最佳状态，找出导致破损的原因并立即解决.
如果我们的一位同事已办理登机手续并且已办理登机手续结果打破了构建，然后有最好的机会修复它，他们需要明确解决问题.当这个规则被破坏时，修复构建不可避免地需要更长的时间.人们习惯于看到构建被破坏，并且很快就会遇到构建一直处于破坏状态的情况.
在提交之前始终在本地运行所有提交测试 : 始终确保为应用程序设计的测试首先在本地计算机上运行，然后在CI服务器上运行它们.这是为了确保编写正确的测试用例，如果CI过程中出现任何故障，则是由于测试结果失败.
对因变更而导致的所有破坏承担责任 : 如果您提交更改并且您编写的所有测试都通过，但其他测试中断，则构建仍然会中断.通常这意味着您已在应用程序中引入了回归错误.您有责任 - 因为您进行了更改 - 修复了因更改而未通过的所有测试.在CI的背景下，这似乎很明显，但实际上在许多项目中并不常见.
