Integrating SonarQube and Reporting Services, by Vinicius Moura

Článek
06/17/2015

This walkthrough, authored and translated from its Portuguese counterpart by Vinicius Moura, aims to provide insightful and practical guidance about integrating the SonarQube platform and Reporting Services installed on existing Team Foundation Server 2013. It presents the configuration and development done to merge Code Quality metrics provided by Sonar and Work Item metrics provided by TFS on same report.

Prerequisites

Team Foundation Server 2013

This guide requires a Team Foundation Server 2013 installation with the following setup:

Build Configuration;
Reporting Services Configuration.

SonarQube

SonarQube Installation Guide from ALM Rangers was used as basis to this walk-through with an objective to integrate the SonarQube platform with an existing Team Foundation Server 2013 setup.
After completing the setup you should have access to the SonarQube portal:

ALM Configurations

This walkthrough will demonstrate ALM on Team Foundation Server based on following:

Backlog Portfolio Management structure based on “One Team Project”
Source Control planning based on TFVC
Build Automation.

Backlog Portfolio Management

The structure for Areas on TFS is based on “One Team Project”. As shown below the root level contains the OneTeamProject node, with three different application system sub-areas.

To filter one Team (e.g. OneTeamProject\SystemA) we set a Default Area, for example SystemA.

The iteration structure represents all Sprints for the development team working on the system.
To filter one Team, we use a default backlog iteration i.e. SystemA

After these configurations, the development team can select an appropriate area and iteration

Source Control Planning

The Source Control reflects the same structure as the Area Path. As with the area and iteration path, SystemA is the node for our development team.

For this walkthrough we are using a branch strategy that allocates a branch for each sprint as shown below:

Build Automation

A Build Automation process uses the Build Process Template “TfvcTemplate12.xaml” (see example in SonarQube Installation Guide), which is versioned on BuildProcessTemplate folder and customized to encapsulate all Sonar calls.

The following changes were made to encapsulate Sonar calls:

Variable’s creation named BuildDetail.
Assign value to variable BuildDetail.
Created arguments:
- BuildNumberSuffix – this argument receive a number version of Build;
- BuildRunnerPath – this argument receive an installation path of “SonarQube.Msbuild.Runner.exe”.
Configuring metadata to not allow the change of the arguments.
On Sequence “Compile, Test and Publish”, include on Build Activity “Assign” called “Assign BuildNumberSuffix”.
- Value = BuildDetail.BuildNumber.Replace(BuildDetail.BuildDefinition.Name + "_", "")
On Build Activity ”Run optional script before MSBuild”, make the Sonar Runner call passing the following parameters.
- FilePath = SonarRunnerPath
- Arguments = String.Format("/key:""{0}"" /name:""{1}"" /version:{2}", BuildDetail.BuildDefinition.Name, BuildDetail.BuildDefinition.Name, BuildNumberSuffix)
  
  The parameters listed above are the arguments of “SonarQube.Msbuild.Runner.exe” command line.
  Each Build Definition will match a “Project Name” on Sonar and each build queuing will be a new version.
On Build Activity ”Run optional script after Test Runner”, make sure the Sonar Runner uses the following parameter.
- FilePath = SonarRunnerPath

Sonar Service API

The Sonar Service API is a WCF service that will be access a REST API of Sonar to list metrics of Builds. This service should be enabled on IIS (Internet Information Services). In short, the service will connect to the REST API and return metrics from a respective “projectKey”. A web.config example shows a connection of Sonar and the list of returned metrics.

sonar.api.url – URL installation of Sonar;
sonar.api.metrics – list of metrics.

When we access “Sonar Service API”, it returns a list of metric and respective last and first matched values as example:

Executing Sprint

After executing ALM Configurations, we must perform the initial setup on each project.

For the example below, we will have the following configuration:

System Name	SystemA
Area Path	OneTeamProject\SystemA
Iteration	OneTeamProject\SystemA\Sprint2
Branch	$\OneTeamProject\SystemA\Dev\Sprint2
Build Definition	OneTeamProject.SystemA.Sprint2 Build Definition Name is based on “Iteration Path” and a Sonar Project.

Initial Sprint Setup

In our example, we have already created the Area and Iteration Path and can create the Work Items using the following process:

We create a branch for isolation of implementing new work that represents the Sprint, with the MAIN branch as parent.

After creating the branch, we define a Build Definition to build the respective branch.

Access Team Explorer menu and click on Build. After click “New Build Definition”
On Build definition name, type a same name of Iteration Path, changing “\” by “.”
OneTeamProject.SystemA.Sprint
On “Trigger” menu, choose “Continuous Integration” option
On “Source Settings” menu, point to their source control of your project.
On “Build Defaults” menu, point to Build Controller and defines a Drop Location
On “Process” menu, choose Build Process Template “TfvcTemplate.12_Sonar.xaml”
On “Process” menu, point to respective solution through “2. Build” “1.Projects” option
Save the Build Definition;
To create a project on Sonar, queue the Build.
At end of execution, the link to SonarQube will be shown.

Each queuing will generate a new version of analysis for this Build Definition.

Important Tips

Creating a new Sprints and Build Definitions, we can use two Visual Studio plug-ins that will help us to manage Build Process.

TFS Productivity Pack – this plug-in clone and remap an existing Build Definition.

Using the example above, if it is necessary create a Build Definition that represent “Sprint3”, we can clone the Build Definition “Sprint2”. See an example below:
- Find a Build Definition “Sprint2” and click on “Branch Build Definition”
- Remap a Source Control
- Rename a Build Definition
Team Explorer Builds Tree – To organize a Build Definition list, install a Team Explorer Builds Tree. It is shown all builds on Hierarchy structure as example below:

Integrating Reporting Services and SonarQube

After configurations and build execution, we can create a report on Reporting Services to show a SonarQube analysis.

Reporting Services will connect WCF Services and show all metrics configured on Web.config.

Follow these steps to create a report:

Connect Reporting Services to WCF Services

Create a new parameter called “projectKey”.
Create a DataSource that connect on WCF Services
Create a DataSet that uses a DataSource created above

<Query>
<Method Namespace="https://tempuri.org/" Name="TimeMachineByProjectKey">
<Parameters>
<Parameter Name="projectKey"></Parameter>
</Parameters>
</Method>
<ElementPath xmlns:a="https://schemas.datacontract.org/2004/07/SonarServiceApi.Contracts" xmlns:i="https://www.w3.org/2001/XMLSchema-instance">
</ElementPath>
<SoapAction>https://tempuri.org/ISonarServiceContract/TimeMachineByProjectKey</SoapAction>
</Query>

After we run the query, we have a following result:

Create “Sprint Project” Report

According to our process where the Iteration Path is the respective Build Definition, we can create a “Sprint Project” Report that shows information about Work Items and SonarQube.

On example bellow, we created a report that lists all Iterations. Therefore, it is possible to connect on SonarQube and show information about “Code Quality” along with Work Item information.

Therefore, we can show a single report that show all information about any project, including planning information and code quality evaluation.

Authored by Vinicius Moura
, an ALM Consultant since 2010 and ALM Ranger since 2012. He has translated guides, such as Extracting effective permissions from TFS and TFS Reporting Guide for the Portuguese community, and is the author of the Work Item Field History VS2013 widget.

Sdílet prostřednictvím