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

Question

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

  

为什么在干净的构建计算机上没有测试更改 - 例如Travis-CI用于提交后测试的那些 - 在提交这些更改之前？

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

Answer 1

假设如果你编写代码并且它编译并且测试是在本地传递的，那么没有构建可能被破坏是错误的。只有这样，如果您是唯一从事该代码的开发人员。 但是，让我说我改变你正在使用的接口，我的代码将编译并通过测试 只要我没有得到你使用我的界面的更新代码。 只要您没有在界面中获取我的更新，您的代码就会编译并通过测试。 当我们都签入代码时，构建机器会爆炸......

所以CI是一个基本上说的过程：尽快把你的变化 并在CI服务器中测试它们（它当然应该首先在本地编译和测试）。 如果所有开发者都遵循这些规则 构建仍然会破坏，但我们会尽快知道它。

Answer 2

CI服务器与版本控制系统不同。 CI服务器也会检查存储库中的代码。因此，当代码在CI服务器上进行测试时，代码已经提交。

可以定期运行更广泛的测试，而不是在签入时，测试时代码的当前版本。考虑多平台测试或负载测试。

通常，在检查之前，您必须在开发计算机上对代码进行单元测试。

Answer 3

我在答案中加上我在GitHub和Jenkins上运行的细节。

为什么开发人员必须在提交之前在本地运行所有测试。特别是在Git范式中，这不是一个要求。例如，如果运行所有测试需要15-30分钟。您是否真的希望您的开发人员或您亲自坐在等待测试在您提交之前在本地运行并推动您的更改？

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

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

我的观点是，当您可以将该工作卸载到Continuous Integration服务器上并获得稍后需要修复的问题时，开发人员在本地运行测试会妨碍他们的进度并不是很好。此外，在您提交并将工件部署到环境之前，某些测试无法运行。如果环境因您没有云而被破坏而且您可能只有一台服务器，那么请在本地修复它并快速推送更改以稳定环境。

如果必须，您可以在本地运行测试，但这不应该是常态。

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