Microsoft Team Build 2008 est l’outil d’intégration continue livré avec Team Foundation Server. Il permet de paramétrer un ou plusieurs builds pour chaque projet de développement créé sous Team Foundation Server.

Un outil puissant, mais pas si simple à mettre en œuvre, surtout s’il s’agit des tests unitaires

Création d’un build

La création d’un build se déroule de la manière suivante :

  • On associe d’abord le build à un espace de travail du gestionnaire de code source, généralement la branche principale.
  • On définit ensuite parmi les fichiers résultats du build, ceux qui sont conservés, et ceux qui ne le sont pas. On parle de stratégie de rétention. La stratégie de rétention peut être définie globalement pour le build, ou individuellement par type de résultat. Il est préférable de limiter le nombre de résultats conservés (ne pas sélectionner « Tout conserver »), et de spécifier individuellement les résultats que l’on souhaite conserver (clic droit sur le build).
  • Il faut ensuite créer un fichier de projet (TFSBuild.proj) pour Team Build. Ce fichier, qui n’existe pas initialement, peut être créé grâce à un wizard.
    • S’il n’existe qu’un seul fichier solution pour le projet dans l’espace de travail, Team Build récupère automatiquement les projets, et les dépendances.
    • Il faut ensuite définir le mode de compilation (debug ou release).
    • Enfin, il reste à définir les tests qui seront exécutés après l’étape de compilation.
  • L’étape suivante est obligatoire. Elle consiste à définir le serveur de build, appelé l’agent de build.
  • Enfin, il convient de paramétrer, si on le souhaite, le mode de déclenchement du build. Dans le cas contraire, le build devra être démarré manuellement. Le déclenchement peut être :
    • planifié dans le temps,
    • ou associé à un événement, comme par exemple un archivage.

Intégration des tests unitaires

L’une des nouveautés de Visual Studio 2008 est l’intégration des tests unitaires dans toutes les versions du produit, et ceci à partir de la version Professional. Les développeurs peuvent donc (enfin !) apprendre à intégrer les tests unitaires dans leurs développements. Team Build 2008 propose d’exécuter ces tests lors des builds, après la phase de compilation.

Pour cela, il suffit simplement de paramétrer les tests dans le fichier TFSBuild.proj. Il existe 3 façons de le faire :

  • soit en pointant vers le fichier vsmdi, sur une ou plusieurs listes de tests. Il est alors impératif de créer au moins une liste de test, et y associer les tests ;
  • soit en précisant un modèle de nommage des assemblys de tests (par exemple, Test*.dll) ;
  • soit en laissant le soin à MSBuild de les extraire, à partir des données du fichier sln, et des assemblys associées.

Un chemin semé d’embuches

Tout semble très simple en apparence ! Il suffit en fait de lancer le build pour se rendre compte que… cela ne marche pas : une erreur indique que le fichier MSTest.exe n’a pas été trouvé !

À cela, il existe une raison aussi évidente que terrifiante ! MSTest.exe est en fait l’exécutable qui permet de lancer les tests dans Visual Studio. Or, cet exécutable n’est pas livré avec Team Foundation Server ou Team Build. Et il n’est pas non plus livré séparément ! Vous me voyez venir. En fait, il vous faut installer Visual Studio (l’IDE) sur le serveur d’intégration continue !!! Au passage, si vous souhaitez utiliser l’outil d’analyse statique de code, alors il faudra installer la version Team System for Developers …

Vous pensiez que tous vos soucis étaient réglés. Et bien, la même erreur apparait au lancement du build : toujours pas de fichier MSTest.exe !

Pas de panique ! Le fichier se trouve dans le répertoire %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE. Il suffit d’ajouter ce répertoire à votre PATH, et de redémarrer le service Team Build. Là, vous devriez obtenir ce que vous cherchiez : un serveur d’intégration continue, qui compile le code et le teste !

Nous pourrions clore ce chapitre ici, mais certains d’entre vous ont peut-être rencontré des problèmes au moment de la compilation, liés à l’absence de fichiers .targets dans les répertoires de MSBuild. Je ne saurai que trop vous conseiller de récupérer les fichiers en cause dans votre environnement de développement (sous Program Files), et les copier bêtement sur votre serveur …

Conclusion

La version 2008 de Team Build est en nette progression par rapport à son prédécesseur, notamment du point de vue de l’intégration des fonctionnalités dans l’IDE. Comme nous l’avons vu, un certain nombre de carences subsiste malgré tout. Sachons néanmoins reconnaitre l’effort fourni, quand bien même la satisfaction ne serait pas totale.

D’ailleurs, je vous conseille de ne pas négliger de comprendre les fichiers XML de configuration de MSBuild, par ailleurs assez obscurs. Ces compétences vous seront fort utiles, lorsqu’il vous faudra modifier le fichier TFSBuild.proj.

Si quelqu’un sait comment réactiver le wizard pour modifier un fichier existant, je suis preneur !