IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Intégration Continue avec Visual Studio et Team Foundation Server - Partie I, Présentation de MsTest et de Static Code Analysis


précédentsommairesuivant

III. Présentation brève des outils de l'intégration continue

Le monde Microsoft (.NET) met quatre outils à notre disposition afin de mettre en place de l'intégration continue sur nos projets. Tous ces outils, bien que pouvant être utilisés indépendamment, s'articulent autour du Team Foundation Server de façon à en tirer le meilleur parti.

III-A. MsTest

L'écriture de tests unitaires est la première étape de l'intégration continue pour garantir l'exécution et la conformité du code vis-à-vis des attentes du client.

De nombreux langages comprennent des frameworks de tests unitaires type xUnit qui ont tous un cœur semblable si ce n'est commun. On peut citer par exemple : JUnit, CppUnit, VbUnit, NUnit, NUnitHttp, .

Tout outil indispensable de la communauté .NET est « destiné » - à plus ou moins court terme - à être intégré à Visual Studio et NUnit n'a pas échappé à la règle. On retrouve en effet depuis Visual Studio 2005 (namespace Microsoft.VisualStudio.QualityTools) un framework très similaire à celui que propose NUnit pour l'écriture de tests unitaires. C'est l'utilitaire MsTest qui permet l'exécution de ces tests. (7)

Il est bien sûr tout à fait possible de continuer à utiliser NUnit pour l'écriture de tests unitaires, mais cela requerra un peu plus de travail si nous voulons automatiser ces tests dans notre build.

Notez que cet outil est installé par défaut dans le répertoire « %ProgramFiles%\Microsoft Visual Studio 8\Common7\IDE » pour Visual Studio 2005 et « %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE » pour Visual Studio 2008.

III-B. Static Code Analysis

Dès la version 1.0 du framework .NET, la communauté Microsoft a mis à disposition des développeurs l'outil FxCop. Il est maintenant intégré dans Visual Studio 2005.

Cet outil (renommé « Static Code Analysis ») permet de faire une analyse statique du code autrement dit une analyse lors de la compilation et non lors de l'exécution.

Il permet de vérifier qu'un certain nombre de règles (paramétrables) ont bien été respectées. On peut citer - entre autres - des règles liées au respect :

  • des conventions de nommage (une classe héritant de System.Exception doit être suffixée par Exception) ;
  • des principes de design (un événement doit avoir une signature acceptant deux paramètres : un System.Object et une classe héritant de System.EventArgs) ;
  • des performances (utiliser const plutôt que shared readonly) ;
  • de sécurité (un constructeur statique doit être privé).

Vous pouvez soit lancer une analyse à la demande (clic droit sur un projet et « Run Code Analysis »), soit la lancer à chaque compilation en activant l'analyse statique dans les propriétés du projet (Clic droit sur un projet et Properties / Code Analysis / Enable Code Analysis).

III-C. MsBuild

MsBuild est la pierre angulaire de l'intégration continue dans le monde Microsoft : c'est l'outil qui permet l'automatisation de tâches diverses (compilation, déploiement d'une solution, exécution de tests…).

La communauté Microsoft avait déjà fourni des outils d'intégration continue - pour la plupart des portages du monde Java - comme CruiseControl.NET et NAnt. Mais c'est à partir de la version 2005 que Microsoft inclut son propre moteur au sein de Visual Studio.

Il est même utilisé en interne pour la compilation des solutions et des projets. Il est donc beaucoup plus « simple » (ou tout du moins envisageable sans refaire tout le processus en ligne de commande) de paramétrer la compilation de nos projets dans Visual Studio en modifiant le fichier de build utilisé par Visual Studio. (8)

MsBuild permet en fait d'exécuter un fichier de projet (ou fichier de build), traditionnellement d'extension « .proj » ou « .target ». (9) Il s'agit en fait d'un fichier XML représentant une série d'actions.

Ce fichier de projet génèrera une fois exécuté un fichier texte comportant tous les messages, avertissements ou erreurs relatifs à l'exécution.

L'outil MsBuild est installé avec le framework, autrement dit dans le répertoire « %Windir%\Microsoft.NET\Framework\VersionFramework », soit typiquement dans les répertoires :

  • « %Windir%\Microsoft.NET\Framework\v2.0.50727 » pour .NET 2.0 ;
  • « %Windir%\Microsoft.NET\Framework\v3.5 » pour .NET 3.5.

III-D. TFSBuild

TFSBuild est une surcouche au-dessus de MsBuild pour réaliser plus facilement de l'intégration continue avec le Team Foundation Server, en permettant de simplifier la création de builds. Il va typiquement exécuter des actions comme :

  • récupération des sources à partir du Source Control ;
  • compilation des sources ;
  • exécution des tests ;
  • publication des résultats sur le Team Foundation Server.

Le build sera alors typiquement considéré comme réussi si :

  • la compilation des sources a réussi ;
  • tous les BVTs sont passés avec succès.

Le processus de build est cependant entièrement paramétrable et il peut donc échouer pour bien d'autres raisons. Nous verrons dans une autre partie comment le paramétrer.

Informations générales sur le build

Image non disponible

Informations générales sur le build




Etapes du build

Image non disponible

Étapes du build : Get, compilation, exécution des tests




Liste des tests et des changesets

Image non disponible

Liste des tests exécutés et résultats

Image non disponible

Liste des derniers changesets (10)


précédentsommairesuivant
Notez d'ailleurs que suite à la sortie de Visual Studio 2005, une nouvelle version de NUnit a été produite afin de suivre le plus possible la direction prise par Microsoft (déclaration des tests par attributs et non plus par convention de nommage) et donc permettre un temps d'adaptation d'un outil vers l'autre quasiment nul.
Notez cependant que le fichier utilisé par Visual Studio est très complexe et dépasse largement le périmètre de ce document. Il est totalement déconseillé de le modifier sans avoir une parfaite connaissance de la syntaxe des commandes utilisées. Il sera cependant beaucoup plus simple pour un projet en particulier de travailler sur le fichier « .csproj » qui est lui-même un fichier de build.
Ces fichiers de compilation (d'extension « .targets ») sont présents dans le répertoire « %Windir%\Microsoft.NET\Framework\VersionFramework ».
Notez que seules ces deux extensions seront reconnues par Visual Studio pour ajouter de la coloration syntaxique et de l'IntelliSense. Notez cependant que l'IntelliSense fournie dans ces types de fichiers est souvent approximative.
On appelle changeset une liste de changements effectués dans le code pendant un commit

Copyright © 2009 Pierre-Emmanuel Dautreppe . Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts. Droits de diffusion permanents accordés à Developpez LLC.