continuous-integration - 如果您可以测试 pre-commit 和 pre-push git hooks，为什么还要测试持续集成？

Question

如果您已经运行了像 Husky 这样的系统，允许您在预提交和预推送之前测试您的代码，那么使用持续集成系统来测试您的代码有什么意义？

score 12 · Accepted Answer

预提交和预推送钩子非常适合快速操作和测试。有时你甚至可以在你的 IDE 中设置一个钩子，它会在你每次保存文件时运行快速的单元测试。但是通常您有多个测试套件，并且与单元测试功能不同，集成和性能测试通常需要更长的时间才能运行，这对于钩子是不可行的。

此外，您希望在构建可交付成果的同一环境中运行测试，这通常不是您的本地机器。

使用 CI 系统的另一个原因是运行合并后测试以验证多个并行合并没有引入问题。

总而言之，您运行的测试越多越好，CI 系统允许您运行通常由某种拉取请求钩子触发的合并前测试和合并后测试。所有这一切都在受控的可靠环境中进行。

score 4 · Accepted Answer

我对它是否在您的本地环境中传递并不真正感兴趣，您的环境路径上可能有一些依赖库的不同版本。我想确定任何人的贡献在链接到我们附带的特定库版本时不会破坏软件。

score 3 · Accepted Answer

使用像 Travis 这样的持续集成平台进行测试的一个原因是确保开发人员没有绕过他们自己的本地开发环境的测试 git 挂钩。

score 1 · Accepted Answer

CI 不仅仅是测试，它还有很多，但测试阶段当然是流程中非常重要的一部分。
正如您在自己的回答中所说，本地环境可以更改，CI 上的测试可以有更严格的设置，您测试的环境可能更像最终用户使用的环境（例如，设置软件版本甚至硬件）。

例如，假设您开发了一个 PHP 包。该软件包支持 php 5.6 和 7.2 之间的所有内容，它还应该支持多种类型的操作系统，并且ext/open_ssl无论是否安装都应该表现不同。本地测试套件很少有允许开发人员在每个所需平台上测试每个可能版本的设置，但在 CI 管道中设置的测试套件可以。

老实说，为了安全起见，再测试一次总是一个好主意！;)

score 0 · Accepted Answer

在某些有用且合理的工作流程中，提交和推送已损坏的提交是可以接受的（尽管不是到 master 分支）。用 git hooks 阻止这样的工作流程很烦人。

以变基或合并为例，即使文件被更改，也不会再次运行挂钩。

钩子也很难正确。他们检查可能不是推送的本地状态（如果存在某些不在 git 中的文件）。

CI 服务器还提供了一个稳定的可预测环境。例如，考虑具有 Linux 的 CI 服务器和使用 MacOs 笔记本电脑的开发人员。git 钩子在 MacO 上运行，它具有不区分大小写的文件系统，即使文件名错误也允许测试通过。

Hooks 还会惩罚那些在提交之前手动运行检查的勤奋开发人员，因为测试只是再次运行一次。

每个专业项目都应该有 CI。真正的问题是，当您已经拥有 CI 时，为什么任何项目都应该维护令人讨厌的缓慢而脆弱的本地挂钩。

仅对私人玩具项目使用挂钩。

5 回答 5