版本控制 – 哪些版本控制程序可以在集成更改之前强制执行测试的
发布时间：2020-12-13 20:09:35 所属栏目：百科 来源：网络整理
导读：在我的工作中,我们目前使用 Aegis版本控制/ SCM.我们配置它的方式,我们有一堆测试,它强制以下事情是真实的,然后才能集成更改： 必须运行全套测试. 所有测试必须通过. 通过测试驱动开发(TDD),这些似乎是明智的要求.但我还没有听说过任何其他版本控制系统可以
|
在我的工作中,我们目前使用
Aegis版本控制/ SCM.我们配置它的方式,我们有一堆测试,它强制以下事情是真实的,然后才能集成更改：
>必须运行全套测试. 通过测试驱动开发(TDD),这些似乎是明智的要求.但我还没有听说过任何其他版本控制系统可以做到这一点. (我们目前不打算转换,但我想知道未来如何在不使用Aegis的情况下进行切换.) 我会对任何能够做到这一点的VCS(分布式或非分布式)感兴趣,我也对现有VCS的任何插件/扩展感兴趣.最好是开源软件. ETA：好的,似乎通常要做的是拥有VCS持续集成软件,并且运行测试是作为构建的一部分自动化的,而不是单独的步骤.如果我理解正确,那仍然允许您提交未通过测试的代码,只是您收到通知 – 是吗？有什么东西可以阻止你完全整合/提交它吗？
如果你想强制你的测试通过,你可以更好地使用像
CruiseControl或
Hudson这样的持续集成系统,并根据测试结果进行构建而不是签入.这些工具设置简单,您可以通过网页获得结果内置通知(通过电子邮件,RSS或浏览器插件)和测试结果报告的优势.
关于问题的更新,您是对的 – VCS CI允许您提交未通过测试的代码;对于大多数CI设置,除非所有测试都通过,否则您将无法获得产品的最终版本.如果你真的想阻止任何人提交,除非所有的测试都通过,你将不得不像其他人所建议的那样在VCS中使用钩子.然而,这看起来很难处理 – 要么开发人员每次进行签到都必须运行所有测试,包括与他们正在制作的签到无关的测试,或者你必须制作一些非常精细的VCS挂钩,只运行与给定签入相关的测试.根据我的经验,依靠开发人员在本地运行相关测试并让CI系统偶尔发现错误会更有效率. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |