【发布时间】：2013-05-24 16:21:49
【问题描述】：
我目前正在处理一个大型 Java 项目，需要以更大更好的方式进行管理。它使用 SVN、Hudson、Sonar。在一天内多次签入后，每晚运行 Hudson 构建，它也运行声纳，因此提供了新的统计信息（代码覆盖率、复杂性等）。但是这些数字目前还不是很有用，因为它们在签到后会告诉情况/数字。
实际情况是，随着每次签入，代码覆盖率都在下降。现在我们要对当前水平的数字进行基准测试。假设代码覆盖率目前为 45% 我们想要的是当且仅当它增加代码代码覆盖率时才应该允许下一次签入，否则不会。
我的问题是如何做到这一点？？
我做了一些研究，知道了两种可能的方法
- 使用 SVN 挂钩
- 使用像 Hudson 这样的持续构建服务器
对于第一个选项找到的链接/教程：Can i run a script when i commit to subversion?
以下两个链接似乎表明第二个选项更好（因为它的签到时间要少得多）
问题
- 由于我还没有配置 hudson（只是作为普通用户使用它来启动构建），我从上面的两个链接中无法理解的是... Sonar 将在签入完成后运行，所以它将如何停止如果某些测试用例失败，用户要签入？还是我的理解不正确？？还是会向所有开发人员发送一封电子邮件，说明签入前后的统计信息？还是只有在测试用例失败时才会发送电子邮件？？
- 我的用例略有不同...在决定是否提交之前，我想检查新的覆盖率 %（包括当前的签入更改）和旧的覆盖率 %（签入更改之前），并且仅在新 > 旧时允许...我如何使用 hudson+sonar 来做到这一点？任何代码/配置示例？？
- 或者我的用例无法通过使用 Hudson ... 而 SVN 挂钩是我唯一的选择？？如果是的话，任何关于如何做到这一点的代码示例
如果我需要进一步澄清我的问题，请告诉我
【问题讨论】：
-
两个观察结果：(1) 覆盖率不能直接转化为代码质量，(2) 解决人员问题的技术解决方案不起作用。
-
for (1) 改变了我现在关心的问题是代码覆盖率% 不是整个代码质量
-
在预提交挂钩脚本中执行此操作会减慢每个人的速度并导致一些非常不利的情况。虽然不是完全重复，但您的问题与this one相似。简短版：你真的应该通过 CI 系统来做这件事，而不是预先提交事件。
标签： java svn hudson build-process sonarqube