看看詹金斯。它轻巧且易于配置。它可以做的是在每次提交后运行一个任务。它可以编译代码、运行单元测试、部署,并且可以完成大多数您认为需要 post-commit 和 pre-commit 钩子的任务。
如果错误地归因于 Jira 问题,我对拒绝提交非常谨慎。发生的情况是更改被偷偷带入其他票证,或者生成了虚假票证并且所有提交都针对该票证发生。我在一家银行,除非有 Jira 票证,否则您无法进行更改,该票证处于打开状态,并且已分配给您。发生的事情是在代码中发现的已知错误未修复,单元测试无法正常工作,并且当开发人员修复内容时,他们只是将其应用于他们知道已打开的票证,与修复无关. Jira 中的信息变得毫无意义。
我做的第一件事是删除预提交触发器并作为开发过程的一部分添加到 Jenkins 中。突然之间,提交变得更快了,开发人员开始自己处理他们发现的问题。随着开发人员确保它可以通过新的单元测试,单元测试的数量增加了,代码也得到了改进。更令人惊讶的是,由于 Jenkins,开发人员开始添加 Jira 票证信息,并提供更详细的提交消息。
Jenkins 通常设置为在每次提交后进行构建。构建可能包括其他内容,例如检查代码、运行单元测试、构建文档以及报告(使用图表)提交中发现的任何问题。Jenkins 甚至可以部署代码并运行功能测试。
但是,每个构建都会显示提交消息。如果提交消息中有 Jira 票证,则有指向该 Jira 票证的链接。更好的是,Jenkins 在 Jira 票证中添加了一条评论,说明此错误是在特定的 Jenkins 构建中处理的(带有返回该构建的链接)。
现在,Jenkins 不仅是一个开发工具,还成为了一个 QA 工具。QA 会发现在 Jira 中标记为已修复的问题,查看修复了该票证的 Jenkins 构建,然后测试该特定构建。(Jenkins 的另一个特性:它可以在每个构建中存储可部署的工件。)。如果需要,QA 可以重新打开问题或报告发现的新错误。QA 不是在 sprint(或发布)的最后加入,而是积极关注开发人员。错误可以在开发人员编写后的第二天检测到,并在第二天修复。
项目经理还发现 Jenkins 和 Jira 是一个有用的组合。他们现在可以准确地说出将部署到生产中的构建。构建在各种环境中进行测试时被标记。没有更多的构建在 UAT 中获得批准,并且开发人员偷偷地进行了一些在生产之前从未测试过的代码更改。
由于来自 QA 和项目经理的压力,开发经理推动他们的开发人员添加良好的提交消息并添加所需的 Jira 票证。此外,开发经理还发现 Jenkins 中的信息很有用。提交消息可以不是孤立地查看,而是针对特定的构建、一组单元测试和功能。甚至开发人员自己也发现这些信息很有用。这是开发人员第一次费心查看提交消息。以前,提交消息毫无意义。开发者主要放入无意义的 Jira 信息,并提交诸如“已修复的错误”之类的消息。现在,提交消息是有意义的,开发人员可以使用它们来跟踪更改。
最后,我们摆脱了 pre-commit 钩子,Jira 票证信息实际上在提交消息中得到了改进。它得到了改善,因为我们改变了组织的文化。好的 CM 就是这样发生的。工具不再妨碍工作。相反,它们对你的工作变得很重要。每个人都看到了软件质量的提高,并成为该过程的拥护者。
现在谈谈你的实际问题:
有代理Subversion 服务器的方法。Wandisco 提供他们所谓的Subversion Multisite,它允许您在世界各地拥有代理 Subversion 服务器。但是,这些主要是为了让远程开发人员拥有本地 Subversion 存储库。Wandisco 确保所有提交都针对所有存储库进行。
问题是您希望您的代理阻止在主 Subversion 存储库中提交。这是不可能的——除非您部署预提交挂钩以强制主存储库等到代理决定是否允许提交发生——您不能这样做。否则,您的代理将没有主存储库中的提交。
此外,为什么要打扰代理?如果您可以设置代理,为什么不简单地使用代理作为您的主要 Subversion 服务器?
但是,您可以在一个小时内设置 Jenkins 服务器,并在 Jenkins、Jira 和您的 Subversion 存储库之间实现真正的集成。你打对了你的牌,你不仅会发现这个解决方案足够好,而且比依赖预提交钩子更好。
如果你把你的开发者当成一群爱发牢骚的小学生,必须仔细观察他们才不会违反规则,他们就会那样做。如果您像对待高素质的专业人士一样对待您的开发人员,他们就会这样做。