Intégration de NDepend dans TFS 2010 – Partie 1

J’ai prévu de vous parler de NDepend et surtout de comment on va pouvoir l’intégrer dans TFS 2010. Intégrer veut dire : lancer l’outil pendant les builds, récolter les résultats et les intégrer dans les bases de données de TFS et éventuellement dans les rapports de build, mais aussi produire des rapports qualimétriques en correlation avec les builds. Du pain sur la planche en somme, et je vous propose de parcourir cela ensemble.

Pourquoi NDepend ?

Je ne suis certes pas le 1er à parler de cet outil (au passage made in France par Patrick Smacchia), en quelques mots, il permet d’analyser vos assemblies et vos sources et afin de vous fournir des statistiques mais surtout d’appliquer des règles de qualité que vous pouvez définir vous mêmes grâce à un langage intégré. C’est donc le compagnon incontournable à mon avis de tout développement un peu sérieux qui vous permettra de mettre le doigt les zones de douleur dans votre code, ou de vérifier que vous avez bien séparé vos couches par exemple.

Entrées et sorties de NDepend

En entrée, NDepend prend donc vos assemblies et vos sources. Afin de pouvoir paramétrer l’analyse on utilise des fichiers .ndproj par analogie avec Visual Studio. L’analyse peut être lancée en ligne de commande, ou bien depuis Visual NDepend qui vous affichera de nombreux écrans interfactifs avec la possibilité de zoomer et de filtrer les axes qui vous intéressent. Nous nous intéresserons d’abord à la génération des rapports NDepend depuis les builds de TFS 2010.

Customiser le Workflow de Build

La 1ère étape de notre petit périple consiste à lancer NDepend au cours de chaque build. Cela va produire un rapport au format HTML que l’on va stocker dans le répertoire de sortie du build, ainsi, si l’on efface le build, le rapport sera jeté avec.

Je ne vais pas m’étendre sur la partie modification de build, d’autres ont réalisé de très bons tutoriaux. Vous avez également la “guidance” qui a été produite par les ALM Rangers il n’y pas plus de 2 semaines et qui est incontournable si vous voulez comprendre les builds en profondeur.

Instructions détaillées

Je suis parti du Workflow de build standard DefaultTemplate.xaml.

Commencez par déclarer RunNDependAnalysis et NDependConsolePath comme variables globales.

Insérez un statement If nommé IfCallNDepend dans l’activité de parallélisation “Get Impacted Tests,…” afin de pouvoir faire tourner l’analyse NDepend en parallèle d’autres traitements post-compilation.

A l’intérieur, collez le bloc “If BuildSetings.HasProjectsToBuild” que vous trouverez à l’intérieur de la séquence “Compile and Test” qui se produit dans l’étape majeure précédente du build (cf image ci-dessous). Nous allons la modifier et l’enrichir.

Renommez les étapes “Try to Compile the Project” "en “Try to Call NDepend”, et aussi  “Compile the Project” en “Call NDepend”.

Puis déclarez les 3 variables suivantes dans Call NDepend :

• ndependProject (String)
• ndependResult (Int32)
• ndependConsolePathExpanded (String)

Maintenant, insérez les éléments manquants dans la séquence Call NDepend pour qu’elle ressemble la version présentée sur l’image, vous devrez rajouter une affectation, une écriture dans le log, une résolution de variable d’environnement, et une invocation de process. Le paramétrage et le détail sont fournis plus bas.

Convert Server Path to Local Path : ne rien changer

Assign : ndependProject <- localProject.Replace(".sln", ".ndproj")

On cherche un fichier ndproj du même nom que la solution.

WriteBuildMessage : "NDepend projet to build " + ndependProject

ExpandEnvironmentVariables :

• Input : NDependConsolePath
• Output : ndependConsolePathExpanded

Permet d’utiliser des variables d’environnement dans le paramètrage du build pour indiquer le chemin vers NDepend.Console.exe.

InvokeProcess :

• Arguments : """" + ndependProject + """ /OutDir """ + System.IO.Path.Combine(BinariesDirectory + "\NDependOut") + """"
• FileName : ndependConsolePathExpanded
• Result : ndependResult
• Handle Standard Output : stdOutput
  • WriteBuildMessage : stdOutput
• Handle Error Output : errOutput
  • WriteBuildWarning : errOutput

On lance l’analyse via le fichier .ndproj, et la sortie sera effectuée au même endroit que la sortie du build.

Lancement du build

Voilà le tour est joué, archivez votre nouveau workflow de build et créez une nouvelle définition de build basée dessus.

Vous pouvez paramétrer le chemin du programme NDepend.Console.exe au niveau de la définition de build.

Avant de lancer le build, vous devrez créer un fichier .ndproj que vous archiverez à côté de votre fichier solution :

• “Ma Solution.sln”
• “Ma Solution.ndproj”

A la fin du build, vous trouverez le rapport très facilement à côté de vos binaires (Open Drop Folder) :

Et voilà le travail dans le sous-répertoire NDependOut :

Lors de prochains articles, nous irons plus loin en intégrant les métriques générées dans les données du build pour une exploitation ultérieure avec TFS 2010 et, à terme, le reporting. A suivre…