Determine your technical debt using SonarQube - Updating your build definitions

Sep 29, 2017


Static analysis will be executed when building your source base using the central build machine. You have two options to set this up with VSTS:

  • Your project is “Visual Studio" related and leverages sln and cs/vb proj files: in that case you can leverage integrated pre and post build tasks provided by the SonarQube VSTS extension.
  • Your project is not build using msbuild: in that case you must leverage the SonarQube CLI task. It’s a little bit more complicated so I’ll demonstrate only the first case for now.

Adding tasks to the build definition

We’ll go under the assumption that you’re already using build 2015/vNext and you have working with build definitions for at least one project.

Edit your build definition and add two SonarQube tasks, place the begin analysis before the visual studio build task and the end of analysis after the execution of unit tests. (that way, if you have code coverage results, they will surface in SonarQube).

Under the “begin analysis" task, set the endpoint, name of project, key to the project, as well as optional parameters if needed.


In my case I also added /d:sonar.exclusions=**/*.min.js,**/*.min.css in optional parameters to exclude minified javascript files from analysis.

Note: these settings can also be specified in the global SonarQube settings or in SQ project settings.

Note: java must be installed on the build machine if you have your own build machines.

Note: I recommend you add a ‘SonarQubeAnalysisTimeoutInSeconds’ variable to the build definition with the following value “600”. This will extend the time-out for the static analysis, sometime your machine to have several results to import at a time, stale a little bit, which can cause builds to take longer and/or time-out.

If you’re working on a non-msbuild project just use the CLI task somewhere after you built and unit tested your code.


Last edited Oct 18, 2021 by Vincent Biret