通过持续集成,为什么测试在提交后而不是之前运行？

Question

虽然我只有一个github存储库,我正在推动(单独),我经常忘记运行测试,或忘记提交所有相关文件,或依赖驻留在我的本地计算机上的对象.这会导致构建中断,但只有在错误提交后才会被Travis-CI检测到.我知道TeamCity有一个预提交测试工具(它依赖于使用的IDE),但我的问题是关于当前使用持续集成而不是任何一个实现.我的问题是

为什么在提交更改之前,未在干净的构建计算机上测试更改(例如Travis-CI用于提交后测试的更改)？

这样的过程意味着永远不会有构建中断,这意味着新环境可以从存储库中提取任何提交并确保其成功; 因此,我不明白为什么CI没有使用提交后测试实现.

Answer 1

我用我在 GitHub 和 Jenkins 上运行的详细信息作为我的答案的开头。

为什么开发人员必须在提交之前在本地运行所有测试。特别是在 Git 范式中，这不是必需的。例如，如果运行所有测试需要 15-30 分钟，该怎么办？在提交和推送更改之前，您真的希望您的开发人员或您个人坐在那里等待测试在本地运行吗？

我们的流程通常是这样的：

1. 在本地分支中进行更改。
2. 运行您创建的任何新测试。
3. 将更改提交到本地分支。
4. 将本地更改远程推送到 GitHub 并创建拉取请求。
5. 让构建过程接收更改并运行单元测试。
6. 如果测试失败，则在本地分支中修复它们并在本地推送它们。
7. 获取在拉取请求中审查的更改代码。
8. 批准并通过所有检查后，推送给 master。
9. 重新运行所有单元测试。
10. 将工件推送到存储库。
11. 将更改推送到环境（即 DEV、QA）并运行依赖于完整环境的任何集成/功能测试。
    • 如果您有云，那么您可以将更改推送到新节点，并且只有在所有环境测试通过后，才能将 VIP 重新路由到新节点
12. 重复 11，直到您完成所有预生产环境。
13. 如果您正在练习持续部署，那么如果所有测试、检查等都通过，则将您的更改一直推送到 PROD。

我的观点是，当您可以将工作卸载到持续集成服务器上并在以后需要修复的问题时收到通知时，开发人员在本地运行测试阻碍他们的进度并不是很好的利用时间。此外，在您提交测试并将工件部署到环境之前，某些测试根本无法运行。如果环境因您没有云而损坏，并且您可能只有一台服务器，则在本地修复它并快速推送更改以稳定环境。

如果需要，您可以在本地运行测试，但这不应该成为常态。

对于多开发者问题，开源项目已经处理了很长时间。他们在 GitHub 中使用分叉，让贡献者有机会提出新的修复和功能建议，但这与团队中的开发人员创建本地分支、远程推送并在推送之前通过代码审查获得团队认可并没有什么不同. 如果有人推送的更改破坏了您的更改，那么您首先尝试自己修复它们，然后寻求他们的帮助。您应该遵循“早和经常合并”的原则，并定期将更新从 master 合并到您的分支。

Answer 2

如果您编写代码并在本地进行编译和测试，则不会破坏任何构建，这种假设是错误的。仅当您是唯一处理该代码的开发人员时才会如此。但是假设我更改了您正在使用的接口，只要我没有获得使用我的接口的更新代码，我的代码就会编译并通过测试。只要您没有在界面中收到我的更新，您的代码就会编译并通过测试。当我们都签入代码时，构建机器爆炸了......

所以 CI 是一个基本上说的过程：尽快将更改放入 CI 服务器中并对其进行测试（当然应该首先在本地进行编译和测试）。如果所有开发人员都遵循这些规则，构建仍然会失败，但我们迟早会知道。