[December 18th 2015: How have we done? Details in line on what’s been done, what’s in progress and what’s still being investigated.]

Back in April (2015) we announced our first step in integrating MSBuild and Team Build with SonarQube, At the start of that post, we briefly explained why we were targeting the problem of managing technical debt, and why we were starting out by integrating with SonarQube – essentially because a lot of customers using or wanting to use SonarQube were complaining about the poor support for analysis of .NET applications. In July we released an updated version (1.0) which supported a broader set of SonarQube plugins that analyze .Net code from MSBuild, simplified installation, provided command-line support, enabled support for build tasks in VSO, and fixed a number of bugs. At the end of August, we announced general availability of build tasks for SonarQube analysis in VSO. Included in that announcement was a useful overview of the options now available to you for analyzing .NET projects with SonarQube. Then earlier this month, we released another update (1.01) of the MSBuild SonarQube Runner with further incremental improvements.

In this post, I highlight some of the key features we are planning to deliver over the next few months for improving support for managing technical debt through continued integration with SonarQube.

Manage Technical Debt – Big Picture

Before diving into the details, it may help to see a big picture of how all the pieces fit together to deliver the whole. This is captured by the diagram below. Debt (code analysis issues, missing test coverage, cloned code, and more) is measured as part of continuous integration, and the data sent up to a technical debt data mart, such as SonarQube. A dashboard helps development teams understand their debt and also put policies in place such as quality profiles and quality gates, as well as establish baselines. The policies and baselines are used to manage the experience for developers so that they can focus on what needs fixing when in the IDE and when viewing pull requests in the web, thereby making it much easier for them to prevent debt being introduced in the first place, as well as remediate existing debt.

Measure Debt

TFS Build tasks

The build tasks that we’ve already shipped and will ship to VSO will arrive in the next update of TFS, starting with TFS 2015 Update 1.

[December 18th 2015: Done. These were shipped with Update 1.]

Java Build tasks

Because there is already integration of SonarQube with Maven, you can add command line arguments in the Maven build task on VSO or TFS to perform SonarQube analysis when building Java applications. However, we are going to make this even easier by providing a custom SonarQube section in our standard Maven task, so it will be as easy to configure SonarQube analysis for Java apps as it is for .NET ones. We’ll also look be looking at Ant, Gradle, and others.

[December 18th 2015: Done. The updated Maven task is available in in Team Services and shipped in TFS Update 1. See The Maven build task now simplifies SonarQube analysis.]

Tech Debt Report in Build Summary

Builds during which a SonarQube analysis happens will provide more information about the evolution of technical debt, with links to dig into the details.

[December 18th 2015: Still to do. We found that changes were need both in SonarQube and our own build system to enable this.]

Understand Debt

SonarQube already provides a fairly comprehensive solution for understanding and drilling into debt across a code base. So the focus of our work here is to make it easier to setup and use SonarQube in a corporate environment using Windows and Active Directory, and then to bring some summary reports direct into VSO/TFS.

Active Directory Integration

We want to make it easy to configure SonarQube to use Active Directory credentials so that, when you are signed in using corporate credentials, you get a seamless experience signing into SonarQube directly or through VSO or TFS. You can also add Active Directory groups easily, and use them to authorize access to SonarQube projects.

[December 18th 2015: Done. See Support for Active Directory and Single Sign On (SSO) in the SonarQube LDAP Plugin.]

One-click install of SonarQube

We will make it really easy to install SonarQube on a Windows machine and configure it to use SQL Server or SQL Express for its database, especially in the case when you want to use it with a TFS server.

[December 18th 2015: In progress.]

SonarQube Widget on VSO/TFS

We will use a SonarQube widget to provide details of the technical debt for your projects on the VSO Dashboard and Home page. Users can link to SonarQube Server from the widget to get a more detailed view of technical debt in the project.

[December 18th 2015: Still investigating.]

TFVC support

We will update the existing TFVC SonarQube plugin, which allows you to view ownership information annotated in source for files stored in TFVC, to work with TFS 2015, and also add support for version control branching and merging scenarios.

[December 18th 2015: Partially done. Works with TFS2015. See Support for Team Foundation Server 2015 in SonarQube TFVC SCM Plugin. We probably won’t do the work for branching and merging. Support coming soon for Team Services when using hosted build.]

Manage, Prevent and Remediate Debt

Tracking Issues through the Backlog

We will enable you to create TFS work items to track progress on fixing (blocks of) issues identified in SonarQube as part of the team’s backlog. This will enable developers and leads to manage and drive down technical debt in their projects more efficiently.

[December 18th 2015: Still to do. It’s taking us and SonarSource time to really uncover what is the useful scenario here. We’re still figuring out when to schedule this.]

Filtering Issues in Visual Studio

It’s not unknown for there to be so many static analysis issues that you decide to turn off static analysis altogether to avoid “warning fatigue”. To help resolve this, we will provide an experience to filter the error list in different ways:

• From a baseline: we’ll give you the opportunity of suppressing issues as won’t fix or deferred. Then you will be able to see/hide the issues for each category. By default, you will see only the issues introduced since the baseline.
• The code you have modified: by adding a filter to show only the static analysis issues that you have introduced since the last check-in or commit.

[December 16th 2015: Done. Shipped with VS2015 Update 1. See section on Code analysis in Visual Studio 2015 Update 1.]

Eventually, it will be possible to drive this experience from baselines and policies defined in SonarQube.

[December 18th 2015: In progress.]

Ensure High Quality Pull Requests

Whenever code is merged into specific branches using a pull request, we will enable you to run SonarQube analysis. You can optionally allow the pull request to be completed only after triaging all the new issues that were introduced in the pull request.

[December 18th 2015: In progress.]