Archive

Posts Tagged ‘sonar’

Sonar and Continuous Integration

July 29, 2009 Comments off

My previous blog was about Sonar – the open source code quality management tool. Deploying Sonar in a machine, and then running it manually for every code change is not desirable for many of us. Definitely there must be an automation step possible, to run Sonar whenever there is a change in the code base. It would be really wonderful if a nightly build or a weekly build software can trigger Sonar, and just publish reports about the violations in the code changes recently done. I never expected it be more easier than integrating Hudson with Sonar. Hudson is a widely used continuous integration tool, that works with any kind of version control software like CVS, VSS, SVN, Clear Case, etc.

Hudson is another web based tool where various types of projects can be scheduled to build in any specific interval. Hudson supports projects with Maven, Ant and those do not have any build script as well. It is quite simple to setup Hudson, just download Hudson and start using the command: java –jar hudson.war.

Before configuring a project, install the Sonar plug-in for Hudson from Dashboard –> Manage Hudson –> Manage Plugins –> Available plug-in list. Hudson must be restarted for the plug-in to be applied.

To setup a project in Hudson, create a New Job from the dashboard. Provide a job name and select what type of project needs to be created.

HudsonNewJob

The next page shows up is the job configuration. There are several options that can be configured, from source code management software, build triggers, build settings and post build actions. The post build actions feature Sonar which must be enabled for Sonar to run automatically after the build is complete. Sonar configurations can also be changed appropriately.

Job Configuration

PostBuildActions

There is a little manual configuration that needs to be done here. The maven project configuration in Hudson does not allow you to specify an absolute path for the pom.xml to be used to build the project. When the project configuration is saved, a workspace directory is created. The pom.xml file used for the project build must be manually copied to the workspace directory for Hudson to perform the build. I wished there is a configuration to specify the pom.xml from any directory. Unfortunately no! Once all the configurations are done, its time to build the project.

From the Hudson dashboard, click on the project name and then do a Build Now, and the project build starts. A progress bar is shown when the build is in progress. Once build is successful, the build history is updated with the build results.

HudsonBuildJob

Now the Sonar dashboard can be accessed to view the updated reports. Sonar over-writes the reports that were generated earlier for the same project. So, to compare results of build history, the version in pom.xml must be changed every time manually before the build.

SonarReportsComparison

The integration between Sonar and Hudson has been very simple and without much manual work. But still more exploration is needed to find out how Sonar can show incremental differences in the violations rather than over-writing the entire report.

With a whole lot of plug-ins and ease of use Sonar, Hudson & Maven can provide a complete build process solution for any organization.

Advertisements

Sonar – Open Source Static Code Analyzer

One of the major challenges in today’s software development lifecycle is effective review and testing of software. There are many ways to perform code reviews and walkthroughs, which depend on the reviewer’s efficiency and experience. It involves lot of manual effort to go through the code line by line, review and analyze the code and find defects.

As far as Java is concerned, there are several code review and standard check open source tools that are being used nowadays. The most predominant are Check Style, Find Bugs, PMD. All these tools are very efficient in their own way. There are eclipse plug-ins for these tools, and can be used during the coding phase to avoid standard errors. They help in finding most of the standard and style errors, during development.

All these tools define rules to check the code for various standard and style violations. The developer can either choose to fix all the violations or can also ignore them. Some of them may not be mandatory to be fixed, and some may cause a serious issue during testing as well as when the software goes live. Also collating the results and analysis from three different tools again involves manual effort. All these activities are error prone.

A better solution to overcome these drawbacks (not all of them) is Sonar. An open source code quality management software, combines the expertise of Check Style, Find Bugs and PMD as well as provides a graphical way of analyzing and reporting code quality. Even though there is no eclipse plug-in or any other graphical editor, setting up of Sonar is quite a cakewalk. Just install Sonar and Apache Maven along with JDK1.5 or above.

Sonar provides support for a whole bunch of platforms, AIX, Linux, HPUX, Mac, Solaris and Windows. Just by running the StartSonar command, the server starts up by creating the schema for the default embedded database, which is Derby. Sonar can also be configured for other database, by changing the conf\sonar.properties.

SonarServer

Once the server has started, the GUI would appear empty without any projects. The default login is admin / admin, for configurations to be changed. Before configuring a project, its better to configure the rules. The Sonar Profiles are by default defined with a lot of rules from Check Style, Find Bugs and PMD.

SonarProfiles

To configure a profile, copy a profile and provide a new name to the profile, then change the rules as necessary. The rules can be made Mandatory, Optional or Inactive. Once the rule levels are defined, then set the new profile to default profile to be used for the projects.

SonarRules

Setting up a project for analysis is also quite simple. If the project is already using maven, then after running the install goal on Maven, then run the mvn sonar:sonar goal from the same directory.

Non-Maven Projects need to create the pom.xml file in any directory. The contents of the file as below:

PomXml

Once the pom.xml is created, then run mvn sonar:sonar to start collecting data for the project. Once the project successfully built, the project will be available in the GUI, for analysis.

Screenshots:

ViolationsSummary        ViolationsDrilldown 

Certain features that could have been made available are the integration with an IDE to fix the problem found either automatically or with a ‘Fix Now’ button and also integration with a version control software for continuous integration and review. Leveraging the Maven APIs and Plug-ins for integration with version control software, the latter can also be achieved.

Overall Sonar is a very useful tool for code quality management. If Sonar can be enhanced with the above mentioned features there is no doubt that it will become a necessity for every developer as well as organizations.