9

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

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

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

4

3 回答 3

5

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

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

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

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

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

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

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

于 2016-02-17T16:21:45.357 回答
3

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

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

当然，一般来说，在签入之前，您会在开发机器上对代码进行单元测试。

于 2013-11-27T12:57:39.013 回答
3

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

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

于 2013-04-19T10:25:05.997 回答