2009-11-17

Creating a Sonar Plugin for software development metrics

As you know, at Zauber we follow high quality standards, that's why we have obtained an ISO 9001:2008 Quality Certification. Part of following these standards implies measuring the performance of our company, getting metrics. Obtaining metrics from our development process allow us to understand our current situation, compare it with previous ones and set new objectives for the future.

Until now, we had three main applications which allowed us to collect information about our projects:

However, there was a problem, these applications didn't show us the metrics in a way that they could be studied through time, and Mantis was too dependent on developers' input, not always enforcing us to provide detailed information about the issues we were working on.(e.g.: sometimes people forget to fill in the 'worked hours' field for a certain issue).

Where to start?

We decided to start using Sonar, a quality management platform that allows analyzing and measuring our projects in a continuous way, displaying our metrics in a very fancy way. To cope with the flaws we mentioned of Mantis, we also developed an application that queries our issue tracker database finding incomplete issues that make references to bugs, reporting them to who may be responsible of them, as well as projects managers.

This way, Sonar became our software metrics dashboard, but we also wanted to include custom metrics collected by our own tool Crono and from Mantis. To achiveve this, we implemented a Sonar plug-in using the Sonar API. But many obstacles flourished on the road while we were implementing this plug-in, the main one was that the Sonar API is vaguely documented or not documented at all, so we had to check out how other plug-ins where implemented, so after studying other plugin’s implementations here is what we've learned

As you can see sonar is somehow similar to the MVC pattern, except that we don't have much access to the logic beneath it. There are some classes you must use in order to make the plugin work

  • The 'Plugin' class which tells the server all the classes this plugin will use.
  • The 'Metric' class which is a list with all the new ways to measure each project, also it references all the information that the view may show
  • The 'Widget' class in this case 'RubyRailsWidget' just gives the location of the Ruby template made on eRuby to render in the sonar page
  • The 'Sensor' and the 'Decorator' are the classes used to gather and process all the previous metrics, the difference between the Sensor and the Decorator is that the Sensor mainly collects information but has no access to what other plugins may collect. On the other side, the Decorator should be responsible for analyzing the information obtained and make cross reference to other information from other plugins.
  • The data that the sensor and the decorator gather is sent to the server through the 'context', which is similar to a "command" class in Spring MVC.

Except for the Sensor and the Decorator, the processes run on the Sonar server. The workflow is the following: First, the Plugin class tells Sonar which classes it uses. Then, when you access the project page, the server calls the widgets classes to obtain the template to render the data on the database. When Hudson runs maven, the latter runs the Sonar plugins, which analyze the project with all the sonar plugins currently installed. Then, the Sensor and the Decorator do their job, saving the metrics information through the Context (the Context will hold a measure for each metric in the class Metric).

What we did

We developed a plugin that uses the previously explained API and Crono REST API. When running it against a project it calculates the total amount of worked hours obtained from Crono, the total amount of rework hours taken from Mantis, and some other information (quantity and category of issues grouped by status). But it is necessary to configure certain settings before obtaining that information. There are two kinds of settings: global settings such as Mantis database URL, Mantis username, Crono URL, username, etc. These can be configured from the plugin settings in the sonar server, and project related settings, such as the project id in the Mantis database or the Crono project unixname in Crono, which are configured in each project maven's pom like these:

52
zauber
zauber-crono
2009-10-5

Where the start date means when the project started in ISO format. Once configured, when sonar analyzes a project, this plugin connects to Mantis and Crono, gets all the necessary information and stores it on the sonar server. After that, when we access a project page, the widget from our plugin is rendered and "voilá": we have our plugin results being displayed like this:

How will this help in the future?

We find this application very useful, because it gives us a complete software metrics dashboard for every project at a glance.

Main Dashboard, a quick view of every project (red column provided by our plugin). Tree-map: a tool that works perfectly when comparing projects on a specific subject. Timeline: a tool that lets you graphically see how the project evolves through time.

We hope that you found this article as useful as developing this plugin was for us. Feel free to contact us if you have any questions.

4 comments:

  1. Great article! Thanks. Did you played back your insights to sonar, so that their documentation is getting better?

    ReplyDelete
  2. @strug, thanks for your comment. In fact we did and we got great feedback from the guys at SonarSource. They are working hard on improving their documentation and adding new cool features in future releases. We'll have to stay tuned for news.

    ReplyDelete
  3. Sounds good. Is there a chanse to get the plugins?

    Mike.

    ReplyDelete
  4. Hello, I am interested in connecting sonar with mantis, is anyway I can get a plugin for this? I have only found a jira plugin. Thanks in advance
    Maria

    ReplyDelete