如果你已经有像Husky这样的系统，可以在pre-commit和pre-push之前测试你的代码，那么使用持续集成系统来测试你的代码的意义是什么？
如果可以在pre-commit和pre-push git hook中进行测试，为什么还要在持续集成中测试？
9
- Rick Bross
5个回答
12
预提交钩子和预推钩子非常适合快速操作和测试。有时您甚至可以在IDE中设置钩子，每次保存文件时运行快速单元测试。但通常情况下，您会有多个测试套件，与单元测试不同的是功能测试、集成测试和性能测试通常需要更长的时间运行，并不适合于钩子。
此外，您希望在构建可交付物的同一环境中运行测试，这通常不是您的本地机器。
使用CI系统的另一个原因是运行后合并测试，以验证多个并行合并引入的问题是否存在。
总之，运行的测试越多，效果越好，CI系统允许您运行预合并测试（通常由某种拉取请求钩子触发）和后合并测试。所有这些都在一个受控可靠的环境中进行。
- Nikita Makarov
1
感谢您提供如此精彩的答案！ - Rick Bross
4
我并不关心它在你的本地环境中是否能通过，因为你可能在环境路径中拥有某些不同版本的相关库。我想要确定的是，任何人的贡献都不会在与我们提供的特定库版本链接时破坏软件。
- Adam G
3
使用类似Travis这样的持续集成平台进行测试的一个原因是要确保开发者没有绕过本地开发环境中的测试git钩子。
- Rick Bross
1
CI 不仅仅是测试，它还有很多其他功能，但测试阶段当然是流程中非常重要的一部分。
正如您在自己的回答中所说，本地环境可能会发生变化，CI 上的测试可能会有更严格的设置，您测试的环境可能更像最终用户使用的环境（例如，设置软件甚至硬件的版本）。
例如，假设您正在开发一个 PHP 包。该包支持 php 5.6 到 7.2 之间的所有内容，并且应该支持多种类型的操作系统，并且如果安装或未安装
老实说，再测试一次总是一个好主意，为了保险！ ;)
正如您在自己的回答中所说，本地环境可能会发生变化，CI 上的测试可能会有更严格的设置，您测试的环境可能更像最终用户使用的环境（例如，设置软件甚至硬件的版本）。
例如，假设您正在开发一个 PHP 包。该包支持 php 5.6 到 7.2 之间的所有内容，并且应该支持多种类型的操作系统，并且如果安装或未安装
ext/open_ssl，则应以不同方式运行。本地测试套件很少具有允许开发人员在每个所需平台上测试每个可能版本的设置，但在 CI 流水线中设置的测试套件可以做到这一点。老实说，再测试一次总是一个好主意，为了保险！ ;)
- Jite
0
在某些有用和合理的工作流程中，提交和推送错误的提交是可以接受的（但不要提交到主分支）。使用git钩子来阻止这种工作流程非常麻烦。
例如，重新基础或合并不会再次运行钩子，即使文件已更改。
钩子也很难正确使用。它们检查本地状态，可能与推送的内容不同（如果存在某些未在git中的文件）。
CI服务器还提供了一个稳定可预测的环境。例如，考虑一个具有Linux的CI服务器和使用MacOS笔记本电脑的开发人员。git钩子在MacOS上运行，其具有不区分大小写的文件系统，即使文件名错误，也允许测试通过。
钩子还惩罚勤奋的开发人员，在提交之前手动运行检查，因为测试只会再次运行一次。
每个专业项目都应该有CI。真正的问题是为什么任何项目都应该维护令人讨厌、缓慢、易碎、损坏的本地钩子，当你已经有了CI。 仅将钩子用于私人玩具项目。
例如，重新基础或合并不会再次运行钩子，即使文件已更改。
钩子也很难正确使用。它们检查本地状态，可能与推送的内容不同（如果存在某些未在git中的文件）。
CI服务器还提供了一个稳定可预测的环境。例如，考虑一个具有Linux的CI服务器和使用MacOS笔记本电脑的开发人员。git钩子在MacOS上运行，其具有不区分大小写的文件系统，即使文件名错误，也允许测试通过。
钩子还惩罚勤奋的开发人员，在提交之前手动运行检查，因为测试只会再次运行一次。
每个专业项目都应该有CI。真正的问题是为什么任何项目都应该维护令人讨厌、缓慢、易碎、损坏的本地钩子，当你已经有了CI。 仅将钩子用于私人玩具项目。
- tkruse
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接