[Nov 2016: Added a status Update with links on details for what was done]

Back in January, I shared with you our SonarQube integration Update and plans for the first half of 2016. I’ve just updated that blog post to ensure that all the links were added to the individual blog posts for the features we have delivered over these last 6 months.

With the Visual Studio Team Services Features Timeline being updated, I can now share what we are planning for the next three months. But first, let’s take a step back and look at what has been achieved so far. Some of these features were produced with our partners SonarSource and the Microsoft ALM Rangers

Retrospective – SonarQube integration with .Net

We are mostly done with the integration of SonarQube with MSBuild projects, especially for C# (SonarSource is still working on improving the experience for VB and C++)

You can easily setup continuous integration builds in Team Services and TFS by adding two MSBuild tasks to your build definition (one before the build, and the other after the tests). With recent versions of SonarQube, you can request the status of quality gates in the build summary. Then, if those fail you will get insights on the reason for this failure. You can also request to break the build when the quality gates fail.

In any case you will get a link from the build summary to the SonarQube projects to dig more into the details, and understand diffs and trends and aggregated metrics.

Picking-up the issues during a continuous integration build means issues are not discovered until after check-in. To prevent this you can request SonarQube code analysis during pull requests, based on a baseline established during continuous integration. SonarQube, acts as a code reviewer adding comments on issues in modified code. This works for any language supported by SonarQube, not only C# and VB (the picture below illustrate pull request with static analysis on JavaScript code)

In the .Net managed languages world, Roslyn analyzers (which enable developers to be notified of static analysis issues as they type), are increasingly important to help controlling technical debt. Therefore, we have enabled Roslyn analyzers authors and SonarQube administrators to create SonarQube plug-ins for Roslyn analyzers using the SonarQube Roslyn SDK. If such plug-ins are present in SonarQube, the corresponding Roslyn analyzer is provisioned as a NuGet package and configured (rulesets will be generated from Quality Profiles) during the continuous integration or pull request build

Finally, if you are working in C# and VB, and are using Roslyn analyzers, you might want your definition of quality in the IDE (Roslyn analyzers nuget packages and rulesets) to match your definition of quality in SonarQube (quality profile). Therefore, we have produced a connected mode in SonarLint for VisualStudio, which enables this consistency by provisioning and configuring NuGet packages for Roslyn analyzers in projects in a Visual Studio solution based on the SonarQube quality profile. It notifies you when your quality definition changes in SonarQube and helps developers to navigate to the bigger picture in SonarQube.

Build tasks, and pull request with static analysis have already been available in Team Services and will be available with the same level of completion (rich build summary) in TFS “Dev15”.

SonarQube support in the Maven and Gradle build tasks will be equivalent to that for MsBuild

Over the past months, we have also started enabling Maven and Gradle build tasks to perform a SonarQube analysis by checking a checkbox. But the build summary is not as nice yet as for MSBuild, in particular, as until recently we did not produce a build summary section for the SonarQube analysis. Also we have not yet enabled pull request with Code Analysis for the Java tasks. In the coming months we are going to enable parity of experience between the MSBuild and the Java build tasks.

Status: Done. See  The Gradle build task now supports SonarQube analysis and Maven and Gradle build tasks support powerful code analysis tools

Broadening support for static analysis tools

We have also started adding support for standalone Java static analysis tools which don’t require a server. So far, PMD analysis is integrated out of the box in the Maven task. We are working on enabling PMD in Gradle and, based on your feedback, we may integrate more tools such as CheckStyle and FindBugs.

Status: Done. See Maven and Gradle build tasks support powerful code analysis tools

A dashboard widget for SonarQube analysis builds

Many of you have requested a dashboard widget for SonarQube. We will produce a widget showing the quality gate status (and reasons for failure if this is the case) as of the last static analysis build of a given build definition. This will work both for MSBuild and Java builds.

Status: On SonarSource’s backlog

Secure installations of SonarQube in Azure

We’ve been working with the ALM Rangers to develop the Azure Active Directory SonarQube plug-in. Currently the ALM Rangers are working on producing an Azure Resource Manager template to deploy a secure installation of SonarQube in Azure.

Status: A first un-secured installation of SonarQube in Azure was done. See Easily deploy SonarQube Server in Azure. Working on securing it.

Security – you consider that this is also part of technical debt

You have told us that security flaws are an important aspect of technical debt. SonarQube has a few rules about security, and this number will increase with time. But we are also working with other partners in the domain of security and technical debt in general to produce more extensions for Team Services and TFS. We’ll update you when these offerings become available in the Visual Studio Team Services marketplace.

Status: In Progress. See Security in Your Continuous Integration Pipeline (on demand video by Sam Guckenheimer), as well as the following article in the MSDN Magazine about Rugged DevOps. More partners will propose extensions.

Introducing architecture dependency validation as part of technical debt

Finally, you have also told us that you consider that architecture flaws are an important part of technical debt. We are working on improving the dependency validation experience in Visual Studio Enterprise, by providing live validation for C# and VB. We’ll also enable these architectural issues to be taken into account in SonarQube through a SonarQube .NET dependency validation plug-in.

Status: Done. See Live Dependency Validation in Visual Studio 2017

We look forward to hearing from you. Please send us your feedback either by asking some questions on this blog post, or proposing suggestions on what you would like us to do next, for instance from User Voice

Thank you!