哪些版本控制程序可以强制运行& 在集成变更之前通过测试吗？
在我的工作中，我们目前使用 Aegis 版本控制/SCM。 按照我们配置的方式，我们进行了一系列测试，并且在集成更改之前它会强制满足以下条件：
- 必须运行全套测试。
- 所有测试都必须通过。
对于测试驱动开发（TDD）来说，这些似乎是合理的要求。 但我还没有听说过任何其他版本控制系统可以做到这一点的方法。 （我们目前不打算进行切换，但我想知道将来如何在不使用 Aegis 的情况下进行切换。）
我对任何可以执行此操作的 VCS（分布式或非分布式）感兴趣对此，我也对现有 VCS 允许这样做的任何插件/扩展感兴趣。 最好是开源软件。
预计到达时间：好的，通常要做的事情似乎是使用 VCS + 持续集成软件，并且运行测试是作为构建的一部分自动运行的，而不是作为单独的步骤。 如果我理解正确的话，那仍然让您提交未通过测试的代码，只是您收到有关它的通知 - 对吗？ 有什么会阻止您集成/提交它吗？
At my work we currently use Aegis version control/SCM. The way we have it configured, we have a bunch of tests, and it forces the following things to be true before a change can be integrated:
- The full set of tests must have been run.
- All tests must have passed.
With test-driven development (TDD) these seem like sensible requirements. But I haven't heard of any way you can do this with any other version control systems. (We're not currently planning to switch, but I would like to know how to do it in the future without using Aegis.)
I would be interested in any VCS (distributed or not) that can do this, I'm also interested in any plugins/extensions to existing VCS that allow this. Preferably open source software.
ETA: OK, it seems like the usual thing to do is have VCS + continuous integration software, and running the tests is automated as part of the build, instead of as a separate step. If I understand correctly, that still lets you commit code that doesn't pass the tests, just you get notified about it -- is that right? Is there anything that would stop you from being able to integrate/commit it at all?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
IMO，您最好使用持续集成系统，例如 CruiseControl 或 Hudson 如果您想强制测试通过，并使构建而不是签入依赖于测试结果。 这些工具设置起来很简单，您可以获得内置结果通知（通过电子邮件、RSS 或浏览器插件）以及通过网页报告测试结果的优势。
关于问题的更新，你是对的 - VCS + CI 允许你提交未通过测试的代码； 对于大多数 CI 设置，除非所有测试都通过，否则您将无法获得产品的最终版本。 如果你真的想阻止任何人提交，除非所有测试都通过，你将不得不像其他人建议的那样在 VCS 中使用钩子。 然而，在我看来这很难处理——要么开发人员每次签入时都必须运行所有测试，包括与他们正在进行的签入无关的测试，要么你必须制作一些非常精细的 VCS 挂钩，仅运行与给定签入相关的测试。 根据我的经验，依靠开发人员在本地运行相关测试并让 CI 系统发现偶尔的错误会更有效。
IMO you're much better off using a continuous integration system like CruiseControl or Hudson if you want to enforce that your tests pass, and make the build rather than the check-in dependent on the tests results. The tools are straightforward to set up, and you get the advantages of built-in notification of the results (via email, RSS or browser plugins) and test results reporting via a Web page.
Regarding the update to the question, you're right - VCS + CI lets you commit code that doesn't pass the tests; with most CI setups, you just won't get a final build of your product unless all the tests pass. If you really want to stop anyone from even committing unless all the tests pass you will have to use hooks in the VCS as others have suggested. However, this looks to me to be hard to deal with - either developers would have to run all of the tests every time they made a checkin, including tests that aren't relevant to the checkin they are making, or you'd have to make some very granular VCS hooks that only run the tests that are relevant to a given checkin. In my experience, it's much more efficient to rely on developers to run the relevant tests locally, and have the CI system pick up on the occasional mistakes.
使用 subversion 和 git，您可以添加预提交挂钩来执行此操作。
听起来你需要看看连续集成（或其变体）。
认为 Git 也有应用补丁的钩子。
With subversion and git you can add pre-commit hooks to do this.
It sounds like you need to look at Continuous Intergration (or a variant of).
Think Git has a hook on apply patch too.
颠覆 和git 都通过预提交挂钩支持这一点。
Visual Studio Team System 通过签入策略原生支持此功能。
我相信 Rational ClearCase 也支持它，尽管我从未见过它的演示，所以我不能肯定地说。
Subversion and git both support this via pre-commit hooks.
Visual Studio Team System supports this natively via checkin policies.
I believe that Rational ClearCase also supports it, though I've never seen that demonstrated so I can't say for certain.
我们使用 git 和 buildbot 做类似的事情，尽管不完全相同。 我们为每个开发人员提供了自己的 Git 存储库，并将 buildbot 设置为在推送到这些存储库之一时进行构建。 然后有人充当集成商，他可以检查构建机器人状态，审查更改并合并他们的更改或告诉他们适当修复某些内容。
您可以使用 Git 来实现此工作流程的多种变体。 如果您不想让某人手动成为集成商，您可能可以将构建机器人设置为在成功时运行脚本，这会自动将该人的更改合并到主存储库中（尽管它必须处理以下情况）自动合并不起作用，并且还必须测试合并结果，因为即使是干净地合并的代码有时也会引入其他问题）。
We use git and buildbot to do something similar, though not quite the same. We give each developer their own Git repository, and have the buildbot set to build any time pushes to one of those repositories. Then there is someone who acts as the integrator, who can check the buildbot status, review changes, and merge their changes or tell them to fix something as appropriate.
There are plenty of variations of this workflow that you could do with Git. If you didn't want to have someone be the integrator manually, you could probably set the buildbot up to run a script on success, which would automatically merge that person's change into the master repository (though it would have to deal with cases in which automatic merge didn't work, and it would have to test the merge results as well since even code that merges cleanly can sometimes introduce other problems).
我相信像 Team City 这样的持续集成软件可以让您进行预提交构建和测试。 我不知道有任何 vcs 直接提供它......可能有一些像你使用的那样，但我不熟悉它们。
I believe continuous integration software such as team city allow you to do pre-commit build and test. I don't know of any vcs that provides it directly...there may be some like the one you use but I'm not familiar with them.
您还可以在 Perforce 中使用预提交挂钩。 而且，如果您是 .NET 商店，则可以将 Visual Studio 配置为要求“门控”签入。
You can also use pre-commit hooks in Perforce. And, if you're a .NET shop, Visual Studio can be configured to require "gated" checkins.
带有自定义工作项的 VSTS，对吧？ 我不认为使用这个有什么问题。 内置报告。 选择自动化。 为什么不？
VSTS with custom Work Items, right? I don't see anything wrong with using this. Built in reporting. The choice to automate. Why not?
我在这里所做的是遵循每个任务分支模式让您测试已经提交到版本控制的代码，但仍然保持主线原始。 有关此模式的更多信息 这里。
您可以在此处找到有关集成策略的更多信息以及有关 Mark 的评论Shuttleworth 关于版本控制的信息此处。
What I do here is following a branch per task pattern which lets you test the code already submmitted to version control but still keeping the mainline pristine. More on this pattern here.
You can find more information about integration strategies here and also comments about Mark Shuttleworth on version control here.
大多数 CI 实现都有一种机制来拒绝不满足所有标准（尤其是通过所有测试）的签入。 他们有不同的名字。
VCS应该做他们最擅长的事情..版本源代码。
Most CI implementations have a mechanism to reject check-ins that don't meet all the criteria (most notably pass all the tests). They're called by different names.
VCS should do what they do best.. version source code.