Java 的持续集成与遗留项目的支持?

发布于 2024-07-28 22:27:03 字数 498 浏览 3 评论 0原文

我知道 Hudson 与 CC 的问题已经被讨论得很厉害了,但我会从另一个角度提出一个问题:其中哪一个(或者可能是完全不同的 CI 产品)适合遗留项目?

我特别需要的是能够在某个日期之前过滤掉问题。 希望使这一点更清楚的一些示例:

  • 不应报告早于 X 的类上缺少的单元测试(或者更好的是,在单独的字段中报告,并应导致构建中断)
  • 静态分析器发现的错误(例如 FindBugs) )在早于 X 的代码中应该报告(或者如上所述 - 单独报告/不应该破坏构建)

推理:期望人们仅仅为了创建 100% 单元而停止他们正在做的任何开发是不可行的-测试覆盖率并修复/分析 FindBugs 报告的所有错误。 一个更可接受的解决方案是确保不再出现任何问题,并且历史类在有人触及它们时就得到解决。 我想要一些产品/项目能够针对这种情况生成适当的报告/警告。

是否有像这样的通用/预配置解决方案,或者我是否需要从头开始构建它(例如,为现有 CI 解决方案之一添加自定义插件)?

I know that the Hudson vs. CC issue has been beaten (discussed) to death, but I would have a question from a different angle: which one of them (or maybe an entirely different CI product) is suitable for a legacy project?

What I would specifically need is the possibility to filter out problems before a certain date. Some examples which hopefully make this clearer:

  • Unit-tests missing on classes older than X shouldn't be reported (or even better, reported in a separate field and should cause the build to break)
  • Bugs found by the static analyzer (FindBugs for example) in code older than X should be reported (or as above - reported separately / shouldn't break the build)

The reasoning: it is unfeasible to expect that people will stop whatever development they are doing just for the sake of creating 100% unit-test coverage and fixing / analyzing all the bugs reported by FindBugs. A much more acceptable solution would be to ensure that no further problems appear, and that the historical classes are resolved when somebody touches them. I would like some product/project which would generate the appropriate reports/warnings for this situation.

Is there a generic / preconfigured solution like this, or do I need to build it from scratch (adding custom plugins for one of the existing CI solutions for example)?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

ま柒月 2024-08-04 22:27:03

对于同样的问题,我采取的方法是:

Hudson 只需进行构建并运行单元测试。 它不报告覆盖率、代码质量等。

然后使用 Sonar 收集和显示代码指标。 Sonar 可以轻松查看每个包的指标细分。 因此,通过命名约定很容易查看代码是否旧,并且代码覆盖率、findbug 等目标较低。

重要的是,它也具有非常好的趋势指标,因此无论是旧代码还是新代码,您都可以查看是否指标正在朝着正确的方向发展。 从很多方面来说,这都是关键点——重要的是方向!

For the same problem the approach I've taken is:

Hudson simply does the builds and runs the unit tests. It doesn't report on coverage, code quality etc.

Sonar is then used to collect and display the code metrics. Sonar can give easy to see breakdowns of metrics per package. So it is easy with a naming convention to see if code is old and has a lower target for code coverage, findbugs etc.

Importantly though it also has very good trend metrics so regardless of whether it is old or new code you can see if the metrics are going in the right direction. In many ways this is the key point - its the direction that matters!

葵雨 2024-08-04 22:27:03

我是持续集成游戏插件的忠实粉丝 Hudson,因为它促进了 findbugs 的使用,添加和修复 javadoc 并修复您收到的任何警告。 您还可以将其设置为为新的单元测试提供分数。

我为一些遗留代码库设置了这个,其中一些是为 jdk1.3 编写的 swing 应用程序。 拥有一个用于改进旧代码的评分系统就像为您的开发团队拥有自己的 SO。

I'm a big fan of The Continuous Integration Game plugin for Hudson as it promotes the use of findbugs, adding and fixing javadoc and fixing any warnings you get. You also can set it up to give points for new unit tests.

I set this up for a few legacy code bases, some are swing apps written for jdk1.3. Having a scoring system for improving old code is like having your own SO for your dev team.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文