Intégrer l'outil de supervision Sonar à Team Foundation Server 2010

Comme on l'a montré dans l'article précédent, Sonar est l’outil indispensable pour évaluer la qualité des projets d’une DSI au fil de l’eau.

Dans cet article nous aimerions présenter l'installation de différents composants de l'analyse Sonar et comment l'intégrer à votre usine de build TFS.

L'installation de Sonar

Sonar est composé de deux éléments : un serveur (base de données + interface web) et un moteur d'analyses, qui va envoyer les résultats en base.

Le serveur de Sonar

La partie serveur de Sonar est très flexible : elle comprend un serveur web minimaliste et une base de données embarquée par défaut, mais peut être branchée sur un moteur de servlet (Tomcat, Jetty) et sur une base de données classique (MySQL, Oracle, SQL Server).

En termes de ressources consommées, il faut compter 500mo de ram et 350ko / 1000 LOC analysées en base de données. A titre d'exemple, la base de la démo de Sonar fait 2Go pour 6 millions de LOC et 2 ans d'historique. Il n'y a donc pas de contre-indication à faire cohabiter Sonar et TFS sur une même machine et une même base.

Le wiki de SonarSource, la société éditrice de Sonar, comporte des instructions détaillées pour mettre en place le serveur.

Les runners de Sonar

Sonar nous propose deux outils pour lancer les analyses de qualité sur nos projets : le "simple java runner" et le plugin sonar pour Maven.

Ces deux runners nécessitent Java 5+ pour fonctionner, sont aussi simples à configurer et s'intègrent facilement dans vos usines de développement. Mais alors que le simple java runner se contente d'effectuer l'analyse Sonar une fois le code compilé, Maven permet aussi d'ordonnancer le build et le déploiement. Ces fonctionnalités supplémentaires ont de l'intérêt lorsque vous utilisez une usine de build multi-langages (Jenkins par exemple).

Que vous choisissiez l'un ou l'autre, la configuration pour Sonar et vos projets C# sera la même, dans un fichier .properties pour l'un et .xml pour l'autre.

Ce fichier de configuration doit se trouver à la racine de votre solution, au même niveau que votre fichier .sln. C'est dans ce fichier que vous renseignerez le nom du programme, la version, les répertoires de sources et de tests et enfin la location du serveur Sonar et de sa base de données s'ils sont sur une machine différente.

Exemple de fichier de configuration basique pour Maven :

<project xmlns="http://maven.apache.org/POM/4.0.0" 
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
	http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	
	<!-- identifiants du projet  -->
	<groupId>com.octo</groupId> <artifactId>projetCSharp</artifactId>
	<version>1.0</version>
	<name>Projet C#</name>
	<packaging>sln</packaging>
	
	<properties>
		<!-- Nom du .sln -->
		<visual.studio.solution>ProjectCSharp.sln</visual.studio.solution>

		<!-- projets de tests -->
		<visual.test.project.pattern>*.UnitTests</visual.test.project.pattern>

		<sonar.language>cs</sonar.language>
	</properties>

	<build>
		<plugins>
			<plugin>
				<groupId>org.codehaus.sonar-plugins.dotnet</groupId>
				<artifactId>maven-dotnet-plugin</artifactId>
				<extensions>true</extensions>
			</plugin>
			<plugin>
				<groupId>org.codehaus.mojo</groupId>
				<artifactId>sonar-maven-plugin</artifactId>
				<configuration>
					<language>cs</language>
				</configuration>
			</plugin>
		</plugins>
	</build>
</project>

Exemple du même fichier de configuration pour Simple Java Runner :

# identifiants du projet
sonar.projectKey=com.octo.projetCSharp
sonar.projectName=Projet CSharp
sonar.projectVersion=1.0

# fichier .sln
sonar.dotnet.visualstudio.solution.file=ProjectCSharp.sln

# répertoires de sources
sources=srcDir1,srcDir2

# répertoires de tests
tests=testDir1,testDir2

# langage
sonar.language=cs

Là aussi, la procédure d'installation du plugin .NET pour sonar est très bien décrite dans le wiki de sonar.

L'intégration à Team Foundation Server 2010

Team Foundation Server (TFS) est l'usine de développement logicielle proposée par Microsoft. Elle est utilisée dans la plupart des grandes DSI adeptes du .NET.

Comme on l'a vu dans l'article précédent, TFS ne permet pas de faire un reporting de qualimétrie aussi poussé que celui de Sonar. Mais par contre, il est relativement aisé d'ajouter l'analyse Sonar au processus de build de TFS à l'aide d'un buildTemplate.

Si on utilise TFS pour builder nos projets, on préférera le Simple Java Runner à Maven. Le runner a besoin des sources compilées, on basera donc notre template sur l'un de ceux disponibles par défault (DefaultTemplate ou UpgradeTemplate) qui s’occupera de compiler le projet.

Enfin, il suffira d'ajouter les activités "Delete/Create/Copy Directory" pour copier les sources dans un répertoire indépendant et "Invoke Process" pour lancer le runner, qui s'occupera d'envoyer les résultats au serveur Sonar.

Les premières versions du plugin Sonar pour .NET prenaient énormément de temps pour faire l'analyse (jusqu'à 1h pour 80kLOC en version 0.2). Mais depuis un gros effort a été fourni par l'équipe responsable de ce plugin et maintenant l'analyse est suffisamment rapide (2-3 minutes) pour être intégrée directement au build Gated Check-In (qui se lance à chaque commit) pour des métriques en temps réel.

Si vous choisissez de faire l'analyse durant un build de nuit, pensez à désactiver le jeu des tests lancés par TFS pour gagner un peu de temps, le simple runner va les jouer lui même.

Pour finir

Les indicateurs de qualité de code fournis par Sonar vous permettront de prendre conscience en temps réel de l'évolution de la dette technique de votre projet.

Attention toutefois, ces indicateurs doivent être compris, notamment les règles de qualité de code, pour pouvoir être paramétrés selon vos besoins. Portez une attention particulière aux règles FXCop et Gendarme : activez les au cas par cas.

Enfin, nous souhaiterions remercier à nouveau l'équipe de développement du plugin .NET pour Sonar, pour la qualité de leur travail.