Feature branch flow and Continuous Inspection - Part 1

In this post i will present one approach to Continuous Inspection using SonarQube that uses feature branch flow in Git to prevent technical debt from leaking into a your main branch. The proposed approach presents and solves many of the current limitations of SonarQube to feature branch flow resulting in a reliable and accurate way of controlling your technical debt. 

Prerequisites: Bitbucket Server (formally Stash), a continuous integration system (Teamcity or other) and SonarQube and MSBuild SonarQube Runner.

When doing feature branch flow, we can identify two stages that affect developers. The first occurs at their desks when they develop their feature and the other when they get feedback in source control server via code review by peers. If you are doing Continuous Inspection with SonarQube we can identify another stage that occurs nightly or sooner and checks the source code base for added technical debt after the feature is merged into the main branch. Usually this is means the completion of the feature is delayed or even worse technical debt as leaked into the source code if not measures have not been taken.

Its then obvious the need to verify the feature branch for added technical debt before the branch is merged. Recently improvements have already been introduced if you are using for example GitHub, with the SonarQube GitHub Plugin, SonarQube Stash plugin or even you can use built in analysis modes provided by SonarQube. Some limitations are found however on the previous approaches, they do not cover all the 7 axis of code quality and in our case we were interested in code coverage, cross project duplication and architecture/design feature the platform provides.

So what was required was a complete analysis and then the integration of this data into the pull request under review. This was achieved by using Sonar for Bitbucket server (formerly Stash), and its level of integration was exactly what we were after.

First, the status page presents and compact summary of new issues, coverage and duplication's. Allowing us to easily spot if new issues have been added in the pull request.

The more interesting features are found when you access the diff view, coverage, duplication and issues are decorated along with the source code. This is a very powerful aid for developers and authors doing reviews.

Tasks can be created easily for issues and the plugin can also be configured to prevent pull request from being merged if quality gates are not passing. 

This by itself already provides plenty of value for a company using feature branch flow, however after using this plugin for different projects we found a few limitations that can make the adoption of the plugin harder for teams. This post presents these limitations and the solutions we found to overcome them.

Limitations of feature branch flow in SonarQube

SonarQube  does not support feature branches - Its a fact that SonarQube does not support feature branches, however items are open to be able to improve this in future see SONAR-2877, SONAR-2877 and SONAR-2210. This means that for now each branch that is analysed is considered as a new project.

This, however is not limiting factor because Sonar for Bitbucket server is able to relate both main and feature branch and provide the comparison between them.

Quality profiles are not shared between main and feature branches - This was a limitation for versions earlier than 5.2, after this version the rest API supports the provision of projects and the configuration of quality profiles. Unfortunately the Bitbucket plugin still lacks this feature, however it can be scripted easily from the continuous integration side.

Configured properties are not in main project not used in feature branch - As the previous limitation properties that are configured in main branch are not applied when a new branch is created. Most importantly the analysis scope might cause plenty of false positives that otherwise are not shown in master branch. Again the rest API allows us to copy those settings from one branch to another. As of now, Bitbucket server does not support this feature.

False positives and resolved issues are not shared between main and feature branches - This was the first thing we spotted when we first started using the Bitbucket plugin, its possible to mark issue as false positive when doing reviews, however this applies only to current branch and they are not synced across.

In fact in my opinion, false positives should not be marked in feature branches, but instead managed only in the main branch by project owner that is responsible by the quality of the project. Therefore false positives in main branch should be copied to the feature branch after the each analysis to reduce the amount of noise in the pull request. This feature is also not available in the Sonar for Bitbucket server.

Quality gates are not shared between main and feature branches - Using rest API is possible also to copy the gates from main to feature branch, so can be scripted also. This is rather useful if you want to prevent the branch from being merged.

Cxx MSBuild Wrapper

To overcome to previous limitations i've created a small wrapper to add the missing functionality, it wraps the SonarQube Msbuild Runner and augments it to provided the necessary features to do feature branch flow. This wrapper also runs static analysis tools to support the C++ Community plugin being its original intent.

The executable can be found in Github or you can use this meta-runner for Teamcity that automates everything. The basic commanding is as follow:

• CxxSonarQubeMsbuildRunner.exe /k:Key /n:Name /v:Version /m:Soluton.sln /b:master /d:sonar.branch=feature_my_feature

This will run the c++ analysis tools (if the project contains c++ code), then it will run provision project, copy profiles and settings and in the end copy false positive and issues resolved as Wont fix to the feature branch.  You're solution will be build during the process also and the begin and end stages of the MSBuild SonarQube runner will also be called. Each time a new commit is added to the feature branch, false  positives are re synced to the feature branch.

The wrapper works in same way as the MSBuild SonarQube runner, with a few added tweaks.

Usage: CxxSonarQubeMsbuidRunner [OPTIONS]
Runs MSbuild Runner with Cxx Support

Options:
    /M|/m:<solution file : mandatory>
    /N|/n:<name : name>
    /K|/k:<key : key>
    /V|/v:<version : version>
    /P|/p:<additional settings for msbuild - /p:Configuration=Release>
    /S|/s:<additional settings filekey>
    /R|/r:<msbuild sonarqueb runner -> 1.0.2>
    /D|/d:<property to pass : /d:sonar.host.url=http://localhost:9000 -> 1.0.2>
    /X|/x:<path for msbuild: default C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe>
    /T|/t:<msbuild target, default is /t:Rebuild>
    /B|/b:<target branch>

Once the wrapper completes, you will be able to access the project in SonarQube server, and once a pull request is created in Bitbucket results will be displayed.

The wrapper is fully compatible with CI builds, and it implements the suggested approach to use SonarQube 5.3 in continuous integration systems. 

The next part of this post i will present the new features available in the VSSonarQubeExtension to support this workflow.

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.