Anyone who has read many of my blog entries or articles will know that I'm a great fan of code quality metrics. By code quality metrics, I am referring to coding standards, best practices, complexity, but also to other associated statistics such as the number of unit tests run and the level of code coverage. Code Quality management is an important part of any project, but sometimes it can be difficult to get a global picture. Any given metric, such as code coverage or code complexity, can be difficult to interpret in isolation. This is where Sonar comes into the picture.
]]>Anyone who has read many of my blog entries or articles will know that I'm a great fan of code quality metrics. By code quality metrics, I am referring to coding standards, best practices, complexity, but also to other associated statistics such as the number of unit tests run and the level of code coverage. Code Quality management is an important part of any project, but sometimes it can be difficult to get a global picture. Any given metric, such as code coverage or code complexity, can be difficult to interpret in isolation. This is where Sonar comes into the picture.
If you are serious about Code Quality management, you should know about Sonar. Sonar is a one-stop shop for code quality metrics. If you are using Maven to generate code quality metrics with tools like Checkstyle, PMD, FindBugs, Cobertura, and/or Clover, forget the standard Maven reports - use Sonar instead! Sonar gives you a dynamic view of both snapshot and historical data coming from all of these tools.
In this article, I go through the basic steps involved in setting up your very own Sonar server in a Linux-type environment (it works for Mac OS too, of course), based on my own experience of installing Sonar on a new build server running on CentOS. It's not too hard. First, download Sonar from the Sonar web site:
$ wget http://dist.sonar.codehaus.org/sonar-1.9.2.zip
$ unzip sonar-1.9.2.zip
$ mv sonar-1.9.2 /usr/local
I like to create a symbolic link to applications like this to make upgrades easier:
$ ln -s /usr/local/sonar-1.9.2/ /usr/local/sonarSonar works with Maven, so you need Maven (2.0.7 is the minimum supported version - it also works fine with Maven 2.1.0). You will also need JDK 5 or higher.
The basic architecture behind Sonar works at two levels. First, your Maven project generates XML metrics, about test results, code quality, code coverage, and so forth. The Maven Sonar plugin takes this data and sends it to your local Sonar server, where it is processed and incorporated into the Sonar database. You can then go to the Sonar site to view your project's code quality metrics.
Sonar stores its data in a real database, so you will need one available. Although it comes with a built-in Derby database, you shouldn't really use this for anything else than testing. For production use, go to the trouble of setting up a dedicated database for Sonar. Sonar works fine with MySQL, Oracle and Postgres. I set up a local MySQL database for this purpose. Here's how they recommend creating the Sonar database in the documentation:
mysql> CREATE DATABASE sonar CHARACTER SET utf8 COLLATE utf8_general_ci;
mysql> grant all privileges on sonar.\* to 'sonar'@'localhost' identified by 't0ps3cr3t';
mysql> flush privileges;
You also need to modify the conf/sonar.properties file to use the correct database. For example, if you are using MySQL, you need to comment out the lines referring to Derby and uncomment (and modify as required) the following lines:
...
# MySql
# uncomment the 3 following lines to use MySQL
sonar.jdbc.url: jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8
sonar.jdbc.driverClassName: com.mysql.jdbc.Driver
sonar.jdbc.validationQuery: select 1
sonar.jdbc.user sonar
sonar.jdbc.password t0ps3cr3t
You can start the Sonar server using the sonar.sh script in the OS-specific subdirectory of the bin directory in your Sonar installation, e.g.
But that's a little boring. Let's implement the Sonar server as a Linux service, so that it will restart cleanly if the server reboots. The existing sonar.sh script is a good place to start. Copy the appropriate script into the# /usr/local/sonar/bin/linux-x86-64/sonar.sh start
/etc/init.d directory, e.g:
# cp bin/linux-x86-64/sonar.sh /etc/init.d/sonar
Now modify the /etc/init.d/sonar file. Add a SONAR_HOME variable pointing to the Sonar installation directory, and a PLATFORM variable matching your platform-specific directory name.
SONAR_HOME=/usr/local/sonar
PLATFORM=linux-x86-64
Next, replace the WRAPPER_CMD and WRAPPER_CONF variables with the following values:
WRAPPER_CMD="${SONAR_HOME}/bin/${PLATFORM}/wrapper"
WRAPPER_CONF="${SONAR_HOME}/conf/wrapper.conf"
Finally, change the PIDDIR variable to "/var/run":
PIDDIR="/var/run"
Now you need to set this up as a service. On Ubuntu or Debian, for example, you might use update-rc.d. On Redhat, Fedora or CentOS, you would use chkconfig
# chkconfig --add sonar
You can now start up the Sonar server as you would any other service:
#/etc/init.d/sonar start
You can now go to the Sonar web page. By default, you will find it on http://localhost:9000/, though you can modify the port and web context in the sonar.properties file if required.
Once your server is up and running, you need to configure your Maven projects to send data to Sonar. This is done using the Maven Sonar plugin.
However, a better approach is to get your CI server to provide the data for you. The key to having good code quality metrics is to have produce them automatically and regularly. A Continuous Integration server is a perfect candidate for the job. For example, you can set up a build job to run a special code metrics build job every night, and send the data to Sonar.
Better still, if you are using Hudson, you can use the Hudson Sonar plugin. The beauty of this plugin is that it lets you integrate Sonar into your Maven projects without changing a line of code. All you need to do is set up the Sonar configuration in Manage Hudson screen. Hudson needs to know how to provide data to the Sonar database, so you need to provide the JDBC connection details.
Next, create a special Sonar build job for each of the projects you want to monitor. Since Sonar treats historical data in 24 hour slices, you only really need to run the code quality metrics on a nightly basis, at least for Sonar. This job just needs to generate the code quality metrics data - you don't need to invoke the Maven Sonar plugin directly. The Hudson Sonar plugin will do this for you - just tick the "Sonar" checkbox further down the screen.
...
Now you should have a Sonar site up and running, complete with (at least) one project. From now on, Sonar will start collecting metrics, and in no time (well, a few days) you will start to have historical data as well as a snapshot of your current project quality metrics. You might also check out the documentation to see what you can do in Sonar.
For anyone interested in learning more about integrating Sonar into a nice open source Java development stack build around tools such Maven, Hudson, Checkstyle, PMD, FindBugs, Cobertura, and so on, come along to one of the Java Power Tools Bootcamps! Starting from the London bootcamp, but also in the other sessions, I will be including a brand-new module on Sonar and how to integrate it into your development stack.
]]>