Hudson Sonar plugin 1.0 : to industrialize the ultimate build system
A couple of weeks ago, we wrote a post on the “The Ultimate Enterprise Java Build Solution“, to show that nowadays the debate on infrastructure has shifted from open source vs commercial to modular vs integrated. Did we mention that we believe in the modular approach ? I don’t think we did but it was obvious, wasn’t it ? ;-)
The solution described by Christopher Jugg is basically what we have in place to run Nemo, the public instance of Sonar : Maven, Hudson, Nexus, Subversion and Sonar. Here is a diagram that shows our Amazon EC2 infrastructure :
Those tools have similarities : they are collaborative, easy to install, easy to configure and doing pretty well what they are supposed to do. With Maven acting as the glue, they all integrate very easily with each others. But beyond that, this overall build system is pretty modular as each tool can be easily plugged or unplugged from the Maven bus. For instance Hudson can be replaced by Bamboo, Nexus by Archiva, Sonar by XRadar, Subversion by GIT, …
About a year ago, we thought that we could even do better by developing a Hudson plugin. The plugin would be an attempt to increase even more the integration between Hudson and Sonar by:
- Enabling full configuration of Sonar through the Hudson interface (no need to change the Maven settings.xml configuration file)
- Recording once the Sonar commands and run them as needed with no extra effort than activating a check box
- Easing configuration of Sonar light mode for non maven projects
This objective was reach last September with the release of Hudson Sonar plugin version 0.2.
Since then, we have used the plugin and have been able to increase without big effort the number of projects in Nemo from 20 to more than 80 which represents 3 millions of lines of code. By combining our own experience on the plugin with the feedback we received, we worked on the version 1.0 :
The plugin is now compatible with the slave mode in Hudson, enabling to work in a cloud and therefore removing any CPU limitation. The next step on Nemo is to use the new Hudson EC2 plugin, in order to only keep one instance of EC2 up at any time and bring other instances on demand for analysis.
Trigger Sonar only by the scheduler
On the contrary of continuous integration, it is not appropriate to run Sonar analysis at every commit on a project. As mentioned in the past, a weekly analysis seems a good frequency, but anything between daily and monthly is fine. So far, you needed two jobs in Hudson to do so : one for continuous integration and one for triggering Sonar. That was a shame because the configuration of both jobs was pretty similar. So we added an option in the plugin to not run Sonar when the job was trigger by polling the SCM.
Sonar version upgrade
This not really a new feature of the plugin, but I thought it was worth mentioning. Since Sonar 1.8, because the bootstrap is done using mvn sonar:sonar, there is absolutely no change anymore required in the plugin configuration when upgrading the version of Sonar.
Version 0.2 was about simplifying configuration, version 1.0 is about being able to industrialize the system ! What we are working on now is the possibility to automatically feed the Hudson violations report (thanks to Anthonin Bonnefoy for his significant contribution on this subject). That would happen by re-using the XML reports generated by Sonar. The violations report will then give a first level of quality reporting embedded in Hudson with no extra configuration work, of course !