The Sonar team is proud to announce the release of Sonar 2.13. This new version includes 60 improvements, bug-fixes and also some new features that we believe are worth stopping your daily work for a couple of minutes to check out : ability to create manual reviews / violations anywhere in the code, ability to create action plans and an extended search engine.

Extended search engine

The search engine will now return not only projects but also modules, package and files. A picture is worth a thousand words :

Add a review on any piece of code

Whenever a quality defect is detected “manually”, the person who detected it has the ability to inject a violation directly into Sonar:

The related violation is then displayed within the source code and will be accounted for in metrics after the next analysis of the project:

Action plans

Action plans can be created to group reviews together.

An action plan can be associated to each violation

And then it is possible to review progress in a widget of a dashboard

Hotpots 2.0

The previous release allowed to use hotspot widgets in its own dashboards (see Sonar 2.12 in screenshots). It’s now possible to customize, rename or even delete the default dashboard named “Hotspots”.

Time now to give a try to the new version and to read the installation or upgrade guides.

Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

Sonar and JaCoCo
By Raghu, 1 December 2011
I am a fan (and regular user) of Sonar, a platform to manage code quality. The 2.12 release of Sonar, which happened yesterday, introduced a bunch of new features including Java 7 support and the availability of Jacoco into Sonar core.

Industrialiser vos projets Flex avec Hudson, Maven, Sonar, FlexPMD et FlexCPD
By Fabien Nicollet, 5 December 2011
Dans le monde Java, il existe de nombreux outils permettant de vérifier l’intégrité de votre code (tests unitaires) mais aussi pour vous assurer que la qualité de votre code est respectée. Ces outils vous permettent d’assurer la robustesse des applications que vous créez.

My Testing and Code Analysis Toolbox
By Jens Schauder, 11 December 2011
Last week we kicked of a “Testing Skill Group” at LINEAS, a group for exchanging knowledge about testing. One question that came up over and over again in various flavors was: What tools are there for testing and analyzing your code? So here is my personal answer for this, in the approximately order I tend to introduce them into projects…

Open Source & code Legacy
By Jean-Pierre FAYOLLE, 18 December 2011
There are more and more solutions of analysis of code which allow to measure the quality of your applications. Most are sold by software vendors, and we had the opportunity to verify that these solutions are expensive to buy, to implement and to use (Disposable software). In response, the last decade has seen the rise of the Open Source alternative to proprietary software.

Flex + ( Ant | Maven ) + Sonar
By Jozef Chutka, 5 December 2011
The title may sound like there are two possible ways how you can have your source code analyzed and published to sonar, but you better do not rejoice prematurely. After spending couple of hours trying to figure out how to make it work using ant I may have hit some nice articles, however sonar-ant-task seems to have major issues with sonar version 2.8. The solution is maven!

Most IT people know Thoughtworks and its charismatic technical leader / evangelist Martin Fowler. But probably fewer know the Thoughtworks Technology Radar whose first publication was done in January 2010.

According to their authors :

The ThoughtWorks Technology Advisory Board is a group of senior technology leaders within ThoughtWorks. They produce the ThoughtWorks Technology Radar to help decision makers understand emerging technologies and trends that affect the market today. This group meets regularly to discuss the global technology strategy for ThoughtWorks and the technology trends that significantly impact our industry.

In its last publication (July 2011), Sonar platform made its first appearance in the “Assess” circle : “Worth exploring with the goal of understanding how it will affect your enterprise”

Of course, SonarSource team was very proud of this but this is not the point here. Indeed, Sonar is a platform to manage quality among other platforms that have been around for a while : CAST Software, McCabe, Klocwork… So why adding now a QA tool to the radar and why choosing Sonar ? Is this because of its growing open source community : 5,000 downloads and 1,000 emails by month ? For its multi-technology capability in Java, C#, COBOL, PHP, PL/SQL, ABAP… ? Is it for is governance extensions: SQALE or Portfolio Management? Maybe, but I am pretty sure that an additional reason has led Thoughtworks experts to make this choice.

From inception, Sonar was not developed as “just yet an other quality reporting tool” but as a mean to continuously manage and fight back technical debt. This might sound like a subtle semantic difference but this actually makes a big difference. SonarSource team has grown with Agile methodologies and with those methodologies, source code is always very much in the center of focus: it should be able to mutate constantly over time to embrace changes. This key capability to do refactoring at any point in time is so important that the Technical Debt metaphor was early introduced by Agile practitioners.

After 4 years of development and 38 releases of Sonar we, at SonarSource, deeply know what “Change” means! In such evolving context, processes, planing, documentation, specifications, … they all matter but what’s about source code ? Some would like to consider source code as a black box without too much value whose development can be easily outsourced. With such an approach, the goal of a quality platform is just to report from time to time how well a blak box comply to some pre-defined quality standards. We do think this is a mistake !

Source code should be considered as a white box that each stakeholder (developer, project manager, IT director, quality consultant, customer, …) can look at any point of time to understand what happens, to initiate discussions and to make decisions. What ever is the quality of your processes, documentation or specifications, bad code will always lead to failure. Therefore when bad code is injected, it should be immediately detected, fought back and analysed to understand why this crappy code has been injected. Waiting several months to detect technical debt is a huge waste as per Lean principles.

Adopting Sonar means much more than simply installing a tool to comply to some QA or security standards … it means that quality of source code really matters and that the ability to daily manage your Technical Debt is key to sustain a continuous delivery approach and to embrace business changes: Continuous Inspection has entered the game !