Improving your gate workflow with action plans and source control support

Today i am going present some new features in 4.0.0 that hopefully will improve the review of introduced debt between gates or versions.

Usually before each software version, some companies might go through some quality gate/process to evaluate if the version is fit for release, one of the criteria to evaluate can be technical debt added during the development process. SonarQube provides a good approach to do this evaluation, differential views provide the information of what has been changed between two versions.

Usually this works well and you are able to review, assign, create plans, etc. The problem that we usually find is that some issues that are raised, are raised because profiles have changed or a new version of a static analysis tool is updated and gives slight different results or reports better results. This usually means you need to review each issue to verify if the issue has been raised against modified code or against old code.

This new introduced feature addresses this issue, now you can combine the previous information with your source control information (currently only git is supported) and filter all issues that have been raised in code that was modified after the selected date.

To do this we go to the issue search tab, and select the date from where we want to apply the filter.

From the example above at total of 327 issues (above major) have been reported, now after checking the filtering on.

We get only 87 new issues, we can now select the new issues and assign those to a new plan.

The issues are now planned to be address for the incoming quality gate. Additionally to this, the same issues can also be added to your favourite issue tracker (currently only Testtrack)

The information will be tracked after this moment in both SonarQube and in your issue tracking system giving the necessary visibility to stackholders to ack accordingly. All this has been performed inside the Visual Studio, reducing a bit the need of jumping between systems.

We have run several of these quality gate checks before and it always takes a few days to review all the new issues. With this new feature, hopefully we can bring this time to only a few minutes. 

VSSonarQubeExtension 1.4.1, a all new look

Version 1.4.1 has just been release, bringing a all new user interface developed on top of mahapps. This is how it looks now.

Additionally  to this, the extension can also be used outside visual studio. A standalone application is available to download here. This standalone application provides the almost  the same features as in visual studio, the user can run analysis and search issues. File analysis is not possible.

Functionally there were also some major changes. With this new version, when using server and local file analysis, we no longer need to enable or disable the analyses. Analyses is automatic and is on by default, bring a better usability to the end user.

Also affecting the status of issues has been greatly simplified. User now can set the status of the issue without considering the issue workflow implemented in the server, by simple bringing the context menu for each issue. 

Another major change was how we now change between modes (server, local and issue search). Now they are totally independent, so issues in the view are preserved when changing modes. For each mode issues in editor are populated accordingly.

On top of this, a new Quality Profile Editor plugin has been included. Users with permissions can now tweak easily the quality profiles used by each project, for example changing the technical debt parameters of the sqale model. 

Other minor features have also been included, so feel free to try the new version. And feedback is always welcome.

SonarQube Local Analysis in Visual Studio

One of the important expects of SonarQube is to provide developers feedback about their work. Typically this occurs once every night, where a CI system normally runs a full blown analysis. This is certainly the case where the code base is large enough that makes it impossible to run continuously.

We have just identified a problem on this kind of setup, there is clearly waste when feedback is delayed, so there is room to improve the process.

Starting in SonarQube 3.4 a new analysis method as been introduced. It was called dryRun, with this method developers were able to run local analysis using for example the issues report plugin and observe their local improvement (or the other way around) of the complete source code base. Although useful the analysis times and the fact that all source code base was analysed were a bit of a feature killer.

SonarQube 4.0 solved this problem by introducing a new method of analysis called incremental mode (and rename of dry run to preview). With this new version of SonarQube developers are now able to run analysis on their local changes. So much of the noise of the preview mode is now removed. Analyses are now fast and only local changes are analysed.

Taking all this into consideration, there is a remaining issue, presenting information to developer. Although the issues report plugin can be used, a developer needs to exit Visual Studio and so it should not be the preferred method. Developers want all this information available in their source code so they can analyze the raised issues in context.

With the release 1.1 of VSSonarExtension this is now possible. Developers can trigger a incremental analysis from visual studio and the raised issues are highlighted straight in the source code after completion.

Let's take for example one of the C++ projects analyses on Nemo. You will need the SonarQube Cpp plugin and the CppPlugin. Other languages like C# and VB .Net are also available in the same websites.

First let's get sources poco:net to our local disk and unzip the sources. Once this is done, lets navigate to the Net folder and open one of the solutions file with Visual Studio.

First thing to do, is to associate the project with the SonarQube project on Nemo, for this first you need to authenticate against Nemo. So lets go to Tools > Options > Sonar and fill in the authentication details as follow:

Lets bring the issues window, from the Sonar Menu and locate the Project section on the window.

We then locate the poco:net, and click associate. Now our solution is associated and a indication of the association is displayed in the status bar.

One of the important parts of the analysis is making sure our analysis parameters are correct, to do this, we need to go to the plugin properties.

The project properties will be enabled if the association is successful. Here we need to locate for example the sonar runner and java binaries. And mostly making sure the parameters are correct. In our example the parameter sonar.sources needs to be set to src, since the main analysis was configured similarly.

The next step is to go to the Analysis section on the issues panel and choose the Local-Incremental analysis method and trigger the incremental analysis, the status bar will become busy indicating a analysis is running. Once its finished we should observe that the issues have been reported in both the issues window and highlighted in the source code. Nice :).

So to summarize, we this new release of the VSSonarExtension we have improved this developer workflow, now a developer can react straight way and fix the source before committing. Reducing the overall waste, improving source code quality and reducing technical debt.