The beginning of a new year always provides a good opportunity to look back at what was achieved the previous year and this is what I am going to do today for the Sonar platform.

Let’s start with a short version of this retrospective. Last year was made of:

• 8 releases of Sonar
• 110+ releases in the ecosystem
• 55,000 downloads of Sonar
• 10,000+ messages on mailing lists

So I suppose we can call this a pretty active year for the community. Now, the longer version:

The Plan

One year ago, we had the following ambitions :

Track changes : The next step is to provide the ability to report on code coverage of new source code. This is to ensure that whatever legacy code is there, teams have the ability to monitor the coverage by unit tests on added code if they wish.

Since Sonar 2.7 and with help of the SCM Activity plugin, this magic feature is available.

Code Review : This is really the next strategic move for the Sonar platform : add a manual dimension to the automated one to provide a complete code review tool.

This was a major change to accomodate into the platform and we therefore decided to adopt a baby step approach. The full functionality was delivered over 5 releases, from 2.8 to 2.12. Here is what the platform now covers:

• Review a violation
• Comment, assign, plan a review
• Flag false-positive violations through the UI
• Create manual violations through the UI
• Change the severity of a violation through the UI

Next step will be to provide the ability to customize the review workflow and its related permissions.

Language consolidation : Provide a Squid-like engine to the C# plugin to make it more robust

It took us 6 month with the great help of Alexandre Victoor to rewrite the C# plugin that embeds its own C# parser and natively supports visual studio projects.

Language consolidation : Improve the C parser to gain robustness, support non ANSI-85 extensions and increase significantly the number of rules available

We haven’t worked as much as we wanted on this C plugin and so the number of rules remains limited. That’s why we’ve already started working to implement the MISRA-C standard.

Language consolidation : Improve the PL/SQL plugin to provide currently missing metrics

A PL/SQL parser has been written to provide all those metrics and to start implementing some new rules outside the Toad CodeXpert tool.

Sonar Eclipse : Now that we have a stable version 1.0 of the plugin, we can start building on it. The objective for this year is to provide capability for running local analysis inside Eclipse

This local mode is now available but in fact the greatest new feature of Sonar Eclipse is certainly the integration of Mylyn to manage reviews directly from the IDE.

Support New Bootstrappers : We have started last year some background work to decouple Sonar from Maven. This work will enable us to support 2 new mechanisms for bootstrapping analysis in Sonar 2.6 : an ANT task and a Java runner. Next step is to also provide Gradle bootstrapper.

DONE, DONE, DONE, Sonar is now fully decoupled from Maven but if you want to use the power of Maven along with Sonar, it is of course still possible.

JaCoCo Integration : We intend to make 2 major integrations of JaCoCo into Sonar this year. The first one is to integrate it into Sonar core. The second one is to provide ANT integration of JaCoCo and therefore provide a simple way of gathering code coverage when you execute unit tests from ANT.

DONE & DONE.

Beyond the Plan

Obviously, we did not plan for all upcoming innovations for the year. Here are three major features of Sonar that weren’t planned and that have been implemented:

• Sonar CPD : this new technology introduced in Sonar 2.10 will fully replace PMD CPD in Sonar 2.14 and allows to track cross-projects duplications
• i18n : Since Sonar 2.10 the Sonar UI can be in spanish, french, greek…
• Email notifications : Since Sonar 2.10 a user can subscribe to some events to be notified by email. For instance when a review is assigned to him.

And this is also true in the ecosystem, here are two examples:

• a great effort made on the PHP plugin to resurrect it
• development of an extension for SAP ABAP

So after all this, what could be an exciting challenge for 2012 ? This is going to be the subject of my next post !

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”

Read the rest of this page »

One of the main objective for Sonar in 2011 is to go a step further in the support of Continuous Inspection. Indeed, prior to version 2.5, Sonar could already take a snapshot of the overall quality of an application and view the evolution of quality measures across snapshots with the TimeMachine service. But this was not sufficient to provide at quick answers to some very valuable questions such as :

• what changed in my application over last 30 days ?
• did quality improve during version 2.7 software increment ?
• which violations have been created since 1st of January and by who ?
• how much is new code covered by unit tests ?
• which projects have increased their technical debt during last 3 months ?
• …

Read the rest of this page »

You probably remember that 4 months ago, we announced the availability of a SQALE plugin for Sonar. Since them, we have continued to work on it and have released a version 1.2. The new version greatly improves the usability of the plugin and makes it even easier for a non-technical manager to understand and manage the technical debt of his portfolio of projects.

Read the rest of this page »

After an initial attempt that ended up posting on what was accomplished last year, time has now come to discuss the plans for Sonar in 2011 and the associated roadmap !

In 2010, Sonar has progressively become a “must have in software factories” as are already Jenkins, Jira, Nexus or Subversion for instance. With Sonar, a quality platform can now be considered as a commodity which can be installed and used by everybody with only little investment whether it is time or money. We will still focus our effort in 2011 to increase the value of the platform and make teams capable of continuously assessing and reimbursing their technical debt even easily than today.

Read the rest of this page »

Six months ago, we would never have believed that one day we would be happy and excited to write about the implementation of a Quality Model in Sonar. Indeed the Quality Models that we knew at the time (most of them are based on ISO 9126 standard) are complex, expensive to implement, can be understood only by an elite of quality experts and are not fun at all. Displaying a global rating on an application is easy but insuring that this rating can be understood in less than 5 minutes by every stakeholder is much more difficult. Implementing one of those Quality Models in Sonar was a kind of non-sense, even if this feature was highly requested by big companies. Indeed they were in contradiction with the vision behind Sonar :

Managing the source code quality should be simple, should be cheap, should be accessible by all stakeholders (developer, architect, project manager, top manager, …), should be valuable and should be fun (without pleasure, perfection cannot be reached) !

Read the rest of this page »

Prior to Sonar 2.2, the home page was simply the list of projects under quality control. Beyond the fact that it did not add much value to the platform, it was unreadable with more than 100 projects and could not even load with more than 800 projects ! This is why we switched the default Sonar home page from an “All Projects” service to a “Filters” service in Sonar 2.2.

Read the rest of this page »

It has now been more than ten years since Kent Beck and Martin Fowler started to talk about Continuous Integration. At that time, it was hard to believe this practice would have such an impact on our daily work and would be so much adopted in the world of software development. Today, we at SonarSource but also in many places, can simply not imagine to go back and work without Continuous Integration.

Here is what can be read about Continuous Integration on Wikipedia :
Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.

The ultimate goal of Continuous is to be able to fire any type of release at any time with minimal risk whether it is a Milestone, Release Candidate or GA : quality requirements become a must-have and no more a nice-to-have. Let’s review which requirements are correctly covered by continuous integration environments today :

• Anybody must be able to build the project from any place and at anytime.
• Every Unit Tests must be executed during the Continuous Integration build.
• Every Unit Tests must pass during the Continuous Integration build.
• The output of the Continuous Integration build is a package ready to ship.
• When one of the above requirement is violated nothing is more important for the team than fixing it.

This is a really a good starting point but does not sound sufficient to talk about total quality . What’s about those other source code quality requirements ?

• Any new code should come with corresponding unit tests (regardless of previous state in code coverage).
• New methods must not have a complexity higher than a defined threshold.
• No cycle between packages must be added.
• No duplication blocks must be added.
• No violation to coding standard must be added.
• No call to deprecated methods should be added.
• …

More generally, those requirements are about keeping overall technical debt under control and only let it increase consciously (see the Technical Debt Quadrant) : this is the concept of Continuous Inspection. This concept seems to have appeared around five years ago (see this IBM Article) and has been recently described and defined (see DZone Refcards 87 about Continuous Integration and Continuous Inspection, see book “Continuous Integration : Improving Software Quality and Reducing Risk” ) but is still an emerging concept as was Continuous Integration ten years ago.

Continuous Inspection requires a tool to automate data collection, to report on measures and to highlight hot spots and defects. Sonar is currently the leading “all-in-one” Continuous Inspection engine. A Continuous Inspection engine can be seen as an Information Radiator dedicated to make the source code quality information available at anytime to every stakeholder. Transparency is certainly one of the main reason why Open Source Software is most of the time of better quality than Close Source Software. A developer writing a new piece of code should always think about the next person/team who will maintain it : Continuous Inspection helps to never forget this golden rule.

But of course, Continuous Inspection only comes after Continuous Integration is solidly implemented : this is the next maturity level and this maturity level can be implemented with Sonar.

Up to version 2.1, Sonar was relying only on external coding rules engines such as Checkstyle, PMD and Findbugs to report violations on Java applications. But since version 2.1, Sonar also provides its own rules engine to work on Java dependencies. This rules engine is based on Squid and three rules are currently available :

Read the rest of this page »

When learning Object-oriented programming, two of the concepts are fairly difficult to understand and therefore to digest : classes must be loosely coupled and highly cohesive. In today’s post, I am going to explain why this is important and how Sonar can help you evaluating how cohesive are your classes.

A few weeks ago, I started a discussion on how to Fight Back Design Erosion by Breaking Cycles with Sonar in which I mentioned that good design should enable to replace any part of a system by a new piece of code with little pain. The first aspect to look at is really the “macro level”, i.e. packages, to ensure for instance that there are no cycles between packages. But to obtain modularity at any level of the design you also need to consider the “micro level”, i.e. the classes / methods, by keeping it loosely coupled and highly cohesive.

Read the rest of this page »