我正在考虑让中央存储库(Mercurial)运行一个pre-commit钩子,验证提交的代码,如果导致构建或单元测试失败,则禁止推送。
显然,这样做的一个缺点是构建需要几分钟时间,会让开发人员在等待期间被卡住。
有没有人做过类似的事情,或者有什么评论?
显然,这样做的一个缺点是构建需要几分钟时间,会让开发人员在等待期间被卡住。
有没有人做过类似的事情,或者有什么评论?
对我而言,这是一种反模式。Mercurial(一个版本控制系统)用于管理源代码的版本,而不是构建系统、持续集成系统、单元测试套件或任何类似的东西。你应该将这样的事情委派给适当的工具,而不是使用预提交钩子。我会使用名为Jenkins(http://jenkins-ci.org/)的开源持续集成套件,并在提交/推送时执行构建/测试等操作。你可以根据构建结果配置Jenkins来执行大量的操作。
pretxnchangegroup
钩子而不是precommit
钩子,因为用户没有提交到中央存储库,他们只是推送到它。你最好让你的持续集成系统监视中央存储库,在有新的变更集时运行构建,并在测试失败时发出警报。 在警报响起之前拉取代码的人将很容易地从犯错的开发人员那里拉取修复。 http://www.youbrokethebuild.com/
我知道它的名字叫做“门禁式签入”或“分阶段签入”。
像微软(我曾在那里工作)和Sun(找不到链接)这样的大公司更喜欢测试系统的附加保证和生产力(“构建不能被破坏,设计上如此”)而不是开发人员的生产力(“签入需要1-2小时”)。只有在小公司或小项目中工作的人通常会对这个想法感到恐慌,但你应该自己算一下。
我见过两种实现方式(并不知道任何产品可以这样做):
* 客户端:用自己的签入工具(CL、GUI)替换常规签入工具,将更改提交到临时分支(或仅将差异文件放在某个临时位置),然后触发一些远程构建代理的执行,该代理将获取更改并执行快速构建和基本测试(即smote测试)。当一切顺利时,更改才真正签入。
* 服务器端:以这样的方式设置您的版本控制,使人们从“稳定”位置获取代码,但将更改推送到“工作”位置(每个开发人员、团队或其他)。然后,当检入到工作位置时,由CI服务器触发,并在成功时自动将它们推送到“稳定分支”,或在失败时将其还原。
我不主张这种方法,只是看看哪种适合您的需求。