Continuous integration for Java with support for legacy project?

Question

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)?

Answer 1

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.

Answer 2

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!