Sonarqube (nee Sonar) is da bomb. It’s not something you have to check daily but if you’re serious about quality you’ll check it during sprint planning if not weekly.
Check out a sample project at nemo.sonarqube.com, e.g., OpenJPA, to get an idea of what information is available. You might want to focus on a specific component at first, e.g., OpenJPA JDBC.
As a developer I’m mostly interested in the “issues” (mostly FindBugs and Squid) and “unit test coverage.” As an architect I’m mostly interested in the “package tangle index” and “complexity” – the former is a measure of proper encapsulation and decoupling and the latter is a measure of maintainability.
It’s important to view these numbers with an appropriate amount of salt. They give valuable insights but it takes a bit of experience to make the best use of them. That’s why it’s important to keep this information away from the bean counters who will set unreasonable standards like 90% code coverage in all unit tests. (This can be impossible to achieve if you have rich exception handling but no way to mock the classes that will throw those exceptions. Only a fool would trade code robustness for a higher score.)
Installing Sonarqube
It’s straightforward to install sonarqube. It comes bundled with its own webapp server and embedded database so you can check it out by just unpacking it and running the startup script. A production system should use a real database. Multiple databases are supported.
Check the sonarqube site for details.
Creating Our Project
I’ll admit it – creating a project is very counter-intuitive. In a nutshell everything is handled by pushing data to the server without creating anything on the sonarqube server first. (You’ll still want to create admin users on the sonarqube server.)
In practice this means that we add a maven plugin. This is an expensive plugin so it’s common to use a custom profile, e.g., “sonar” (for the legacy name).
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<profiles>
<profile>
<id>sonar</id>
<properties>
<sonar.language>java</sonar.language>
<sonar.host.url>http://chaos:9000</sonar.host.url>
<sonar.jdbc.url>jdbc:postgresql://chaos/sonar</sonar.jdbc.url>
<sonar.jdbc.username>sonar</sonar.jdbc.username>
<sonar.jdbc.password>sonar</sonar.jdbc.password>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.6.4.201312101107</version>
<executions>
<execution>
<id>default-prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>default-prepare-agent-integration</id>
<goals>
<goal>prepare-agent-integration</goal>
</goals>
</execution>
<execution>
<id>default-report</id>
<goals>
<goal>report</goal>
</goals>
</execution>
<execution>
<id>default-report-integration</id>
<goals>
<goal>report-integration</goal>
</goals>
</execution>
<execution>
<id>default-check</id>
<goals>
<goal>check</goal>
</goals>
<configuration>
<rules>
<!-- implmentation is needed only for Maven 2 -->
<rule implementation="org.jacoco.maven.RuleConfiguration">
<element>BUNDLE</element>
<limits>
<!-- implmentation is needed only for Maven 2 -->
<limit implementation="org.jacoco.report.check.Limit">
<counter>COMPLEXITY</counter>
<value>COVEREDRATIO</value>
<minimum>0.60</minimum>
</limit>
</limits>
</rule>
</rules>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
Updating Our Project
The sonar plugin is expensive so it should not be run as part of a routine build. A common practice is to schedule a nightly build on the CI server (Hudson, Continuum, etc.) Developers may also want to perform off-schedule builds while working on the issue backlog – it’s not uncommon for one fix to introduce other lower-priority issues.
Source Code
A sample project using this plugin is at https://github.com/beargiles/project-student [github] and http://beargiles.github.io/project-student/ [github pages].
This project illustrates the need to be intelligent about how we interpret the results. I use two common practices – throwing an internal exception instead of returning a null value and using a custom ‘UnitTestException’ to test failure code without cluttering the logs with extraneous information. The code looks the same as questionable code so it’s properly flagged but there doesn’t seem to be a way to silence squid warnings. (Findbugs has its own SuppressWarnings annotation.)
Overall it’s still a huge win.
(Update: it’s possible to control the squid warnings via the sonarqube ‘Quality Profiles’ tab. This can be used to reduce the severity level to ‘info’ but I’m hesitant to disable these tests outright since they are sometimes legitimate warnings. That’s why I strongly prefer to use per-instance FindBugs SuppressWarnings annotations instead of changing those warning levels.)
