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.
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.
