Back in September Stuart explained our SonarQube Integration plans with Visual Studio, TFS and Visual Studio Team Services. In December he updated the blog post with what we had done.
With the Visual Studio Team Services Features Timeline being updated, now seems the right moment to recapitulate what we did, and explain what we’re planning over the next six months.
Goals of the integration work
Our goals for the integration work are and have been:
- Unblock .NET/MSFT developers from using SonarQube for analyzing .NET and other code built using MSBuild
- Integrate SonarQube with VSTS/TFS, by providing parity (or better) SonarQube integration with VSTS/TFS when compared to other ALM/DevOps systems
- Improve the Developer experience managing the technical debt. Round out the overall end to end solution for managing technical debt by providing developer experiences to identify and clear it, governed by quality profiles defined in SonarQube
- Ease the installation of SonarQube on Windows and Azure, making it easier for teams to install/host and secure SonarQube server on Windows and Azure
What we shipped (partnering with SonarSource as needed)
In the table below, the features that were described in the SonarQube Integration plans blog post are organized by scenario (as described in that post). We’ve also added a column explaining the particular problem that the feature is targeted at solving.
Scenario | Problem Solved | Feature Delivered |
Continuous measurement | SonarQube did not work well with .NET. This was the starting point at the beginning of 2015. | SonarQube analysis of .NET integrated with MSBuild. SonarSource released several incremental versions of the SonarQube scanner for MSBuild (which was originally named SonarQube MSBuild runner), and generally got the feedback that analyzing .Net code is no longer a problem. |
SonarQube was not integrated with TFS / VSTS build | The SonarQube analysis Build tasks and the Maven task in Visual Studio Team Systems and TFS 2015 Update 1 provide a nice integration with Build (see Build Tasks for SonarQube Analysis and The Maven build task now simplifies SonarQube analysis) You can read Quickstart: Analyzing .NET projects with SonarQube, MSBuild or Visual Studio Online, and third-party analyzers (StyleCop, ReSharper) which covers most of the Continuous measurement scenario. It’s also still possible for users of previous versions of TFS to leverage the XALM build customization (See Analyzing projects in XAML Builds in TFS 2013 and TFS 2015) | |
Dashboard and Datamart | “Blame” annotations telling who probably introduced a static analysis issue didn’t work as well in SonarQube for TfVC as for Git | The TFVC Plug-in is quicker and works with TFS 2015. See Support for Team Foundation Server 2015 in SonarQube TFVC SCM Plugin |
Active directory was not well integrated | LDAP plug-in supports Active directory (AD) authentication and single-sign-in on Windows. See Support for Active Directory and Single Sign On (SSO) in the SonarQube LDAP Plugin | |
SonarQube did not work well with SQL Server | From SonarQube 5.2 the SonarQube database can be an Azure SQL database. It’s also possible to leverage the SQL Server integrated security. | |
Developer Experience | Wall of issues in Visual Studio Error List | We got the feedback many times from customers that using the static analysis issues was very overwhelming. We worked with the static analysis team in Microsoft to provide features to: - Suppress all active issues for .NET (stop-the-leak) - Filter to changed files in VS (clean-up-as-you-go) See the //connect 2015 on demand video : Manage your technical debt with TFS, Visual Studio Team Services, Visual Studio, and SonarQube |
Plan for 2016H1
Scenario | Problem to be Solved | Feature to be Delivered |
Continuous measurement | Roslyn analyzers are not considered by SonarQube. So far, SonarQube was using its own C# plug-in which contained some of the SonarLint for Visual Studio rules, but not all. There is now way to take into account the result of other Roslyn analyzers (whether general purpose as the ones we just mentioned, or domain specific in your organization) | Roslyn analyzers will be Provisioned and configured from SonarQube Quality Profile in Analysis Builds We are working on an SDK enabling authors of Roslyn analyzers or SonarQube administrators to generate SonarQube Plugins for these analyzers. We also are enabling the MSBuild SonarQube scanner to consume these Roslyn plug-ins. This happens by provisioning them (adding the nuget packages if necessary) and configuring them (by generating the right rulesets from the SonarQube quality profile) As a first step the MSBuild SonarQube Scanner 1.2 was released last week, which provisions and configures the SonarLint analyzers (See SonarQube Scanner for MSBuild v1.1 released: static analysis now executed during the build). This will be extended to any Roslyn analyzers by the end of this month |
No single-glance view of the code quality in a build | Improved SonarQube analysis build summary, providing a better sense of the code quality in a build | |
ASP.NET v5 projects cannot be analyzed | The perfect solution is dependent on ASP.NET v5 project systems supporting Roslyn analyzers. In the meantime, we will provide an interim solution. | |
Dashboard and datamart | No single-glance view of overall code quality | Dashboard widget summarizing the quality of the code |
SonarQube integration parts are visible, discoverable to customers and released frequently | We released a SonarQube extension for VSTS/TFS in the Visual Studio marketplace. We are going to add more parts in this extension with time, including dashboard widgets, and improved summary for the build tasks. The extension will also be installable in TFS, when support for the arrives in TFS Update 2. | |
Azure Active directory is not well integrated | SonarSource will enable users to log-in in SonarQube using Azure Active directory credentials | |
Blame annotations don’t work with VSTS | The TFVC Plug-in will now work with VSTS (will be released part of the SonarQube SCM TFVC plug-in 2.1.1) | |
Installing SonarQube in Azure is not that easy | We’d like to provide a SonarQube Azure Resource Management template to help administrators doing SonarQube installations | |
Developer Experience | SonarQube integrates with GitHub pull request, not VSTS / TFS | SonarQube analysis results will show in pull request view on VSTS. We are building an experience enabling SonarQube analysis to be done on a continuous integration build triggered by a pull request on a Git repository in VSTS or TFS (ETA TFS Update 2). The results of the analysis violating the quality gates are available as pull request comments. Optionally, build administrators can set a policy requiring the author of the pull request to answer all the code review comments |
Inconsistency between developer experience and pull request / analysis builds. Need for governance (provisioning, configuration from a central definition of the quality) Today developers can be surprised by the results of a continuous integration build and in a future, they will be surprised by the issues in pull request comments. We got the feedback they would like to be warned as early as the development in the IDE | Roslyn analyzers in Visual Studio will be provisioned and configured from a SonarQube quality profile. We are working on connecting a Visual Studio solution to a SonarQube project, and, as a consequence provisioning and configuring Roslyn analyzers in the Visual Studio projects governed by quality profiles defined in SonarQube |
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!