A new year provides a good opportunity to look back at what was achieved the previous year. This is what I am going to do in this post for the Sonar platform.

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

• 6 releases of Sonar platform
• 200 releases of ecosystem products
• 65,000 downloads of Sonar
• 12,000+ messages on mailing lists

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

Read the rest of this page »

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 »

At SonarSource, we like eating our own dog food as much as possible. This is not always the case in software development, but in our case since we develop software for software companies, we can do it. We therefore have an instance of Sonar that analyses all our products daily. We’ve been using it for quite a long time to monitor code quality using features like alerts and SQALE indicators (Technical debt). We have defined a quality gate for the ecosystem that is fairly simple: the SQALE index must be A, the technical debt must not increase between releases and there must not be blocker or critical violations.

This quality gate is good to have but not efficient enough because defects introduced during a sprint have to be fixed all at the end. Instead, they should be fixed as they appear for better efficiency, similarly to code fix when a unit test breaks in continuous integration: this is what we call continuous inspection. We have done a lot of work this year to be able to provide better support for Continuous Inspection in Sonar and have added several services : differential views, SCM information and manual reviews integrated with email notification and with Sonar Eclipse. Manual reviews is really the new hot feature to complements existing services and making code reviews more effective.

How does this all fit together ? Well, this is the subject of this post… Get your Sonar 2.11 started, open Eclipse along with Sonar Eclipse 2.1, and follow the guide!

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 »

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 »

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.