在推送时构建和单元测试？

Question

我正在考虑让中央存储库（Mercurial）运行一个pre-commit钩子，验证提交的代码，如果导致构建或单元测试失败，则禁止推送。

显然，这样做的一个缺点是构建需要几分钟时间，会让开发人员在等待期间被卡住。

有没有人做过类似的事情，或者有什么评论？

- moswald

Answer 1

对我而言，这是一种反模式。Mercurial（一个版本控制系统）用于管理源代码的版本，而不是构建系统、持续集成系统、单元测试套件或任何类似的东西。你应该将这样的事情委派给适当的工具，而不是使用预提交钩子。我会使用名为Jenkins（http://jenkins-ci.org/）的开源持续集成套件，并在提交/推送时执行构建/测试等操作。你可以根据构建结果配置Jenkins来执行大量的操作。

- Jeremy Whitlock

Answer 2

被称为门控提交或预测试提交。一些CI系统支持，一些不支持。以下是关于TFS实现此功能的博客文章:http://spandothers.wordpress.com/2010/06/08/tfs-2010-gated-check-ins/。个人认为这只是一个普通的功能，提交代码，出现错误，修复它，然后继续进行。破坏构建不应该成为一个大问题。

- Ritch Melton

---

破坏构建不应该是一个大问题。99次中有98次我同意你的观点。这个问题的产生正是因为那1次我没有同意。阅读这句话提醒我不要过早下结论。 - moswald

我曾在一家使用夜间构建的商店工作。如果开发人员破坏了构建（因为构建需要很长时间），管理层会惩罚他们和其他开发人员。最终，我们转向了CI，将事情分开，并让我的项目部分不断构建，尽管不是完全连续的。管理层和开发人员花了多年时间才克服惩罚心态。CI、版本控制、IDE都是开发人员的工具，而不是管理层的工具。如果你让管理层向这些工具添加功能，你只会阻碍开发人员进行更改和改进代码。 - Ritch Melton

不知道。这个点赞算是补偿吧。顺便说一下，我没有采用我的提议。我认为你是对的，即即使出现构建失败也没有问题，特别是当你有一个 CI 机器来跟踪好坏构建历史记录时。 - moswald

@mos - 谢谢。恶意投票真让我烦恼。虽然处罚很小，但是烦恼却很大。 - Ritch Melton

Answer 3

本文讲述如何使用钩子处理存储库事件，详细内容请参考这本Mercurial书 http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html 。以下是一些要点：

• 您需要使用pretxnchangegroup钩子而不是precommit钩子，因为用户没有提交到中央存储库，他们只是推送到它。
• 确保仅测试推送的更改组中的最新更改集，以便人们可以纠正错误并重试推送
• 在测试运行时，存储库将被锁定以阻止所有其他推送，这真的破坏了DVCS的一半意义

你最好让你的持续集成系统监视中央存储库，在有新的变更集时运行构建，并在测试失败时发出警报。 在警报响起之前拉取代码的人将很容易地从犯错的开发人员那里拉取修复。 http://www.youbrokethebuild.com/

- Ry4an Brase

Answer 4

我知道它的名字叫做“门禁式签入”或“分阶段签入”。

像微软（我曾在那里工作）和Sun（找不到链接）这样的大公司更喜欢测试系统的附加保证和生产力（“构建不能被破坏，设计上如此”）而不是开发人员的生产力（“签入需要1-2小时”）。只有在小公司或小项目中工作的人通常会对这个想法感到恐慌，但你应该自己算一下。

我见过两种实现方式（并不知道任何产品可以这样做）：
* 客户端：用自己的签入工具（CL、GUI）替换常规签入工具，将更改提交到临时分支（或仅将差异文件放在某个临时位置），然后触发一些远程构建代理的执行，该代理将获取更改并执行快速构建和基本测试（即smote测试）。当一切顺利时，更改才真正签入。
* 服务器端：以这样的方式设置您的版本控制，使人们从“稳定”位置获取代码，但将更改推送到“工作”位置（每个开发人员、团队或其他）。然后，当检入到工作位置时，由CI服务器触发，并在成功时自动将它们推送到“稳定分支”，或在失败时将其还原。

我不主张这种方法，只是看看哪种适合您的需求。

- Uri Cohen