Intégration Continue avec Visual Studio et Team Foundation Server - Partie II, Présentation de MsBuild et de TfsBuild

Il serait vain de vouloir présenter le Team Foundation Server en quelques lignes alors que des livres entiers lui sont consacrés.

Je vais me contenter ici de présenter brièvement certaines des fonctionnalités de l'outil.

Le TFS intègre un Source Control puissant que Microsoft conseille d'utiliser pour les grandes entreprises. On y retrouve les fonctionnalités de vos Source Control préférés (SourceSafe ou SubVersion par exemple) dans un outil parfaitement intégré à Visual Studio.

Il inclut également un système d'intégration continue : à la fois un langage pour écrire des fichiers d'automatisation / de build, semblable à NAnt, mais également un serveur d'intégration appelé « Build Server ». C'est ce serveur qui va permettre de récupérer les sources à intervalle régulier et de lancer des tests.

Pour cela, on va créer des « Build Agent » avec lesquels le TFS va communiquer pour lancer les builds automatisés.

Le TFS propose également de gérer des Works Items, soit un système de gestion de tâches et d'incident. Ce système est directement couplé avec le mécanisme de build automatisé puisque dès qu'un build échoue, une nouvelle tâche sera créée automatiquement.

Enfin, il nous offre également des guides / templates de gestion de projet qui permettent entre autres de configurer plus facilement l'outil selon notre mode de fonctionnement.

Client : L'utilisateur / développeur qui va se connecter au Team Foundation Server a installé Visual Studio et le Team Explorer. Le Team Explorer peut-être vu comme un plugin de Visual Studio permettant la connexion et les interactions avec le TFS.

Team Server proxy : Ce composant (facultatif) sera typiquement utilisé sur des sites importants. Il permet de mettre en cache les requêtes faites au Team Foundation Server afin d'améliorer les performances. Typiquement ce proxy sera installé dans chacun des sites (société) qui vont se connecter sur un même Team Foundation Server.

Team Foundation Server : Il s'agit du serveur proprement dit, composé de l'« Application Tier » et du « Data Tier ». Ces deux tiers peuvent être installés sur le même serveur ou sur deux serveurs différents. Le « Data Tier » est toujours transparent pour l'utilisateur qui ne communiquera qu'avec « l'Application Tier ». Le « Data Tier » se repose sur Sql Server 2005. Notez que le TFS 2010 ne fonctionnera qu’avec Sql Server 2008.

Team Build Server : Il peut être installé sur un serveur dédié ou sur le Team Foundation Server. C'est le serveur sur lequel seront exécutés les builds demandés sur le serveur

Le Team Foundation Server repose sur Active Directory et sur ADAM pour gérer les droits. Il est possible via le Team Explorer de paramétrer les droits des différents utilisateurs ou groupes.

Les droits peuvent être modifiés par un administrateur du Team Foundation Server selon la procédure suivante :

• aller dans le Team Explorer ;
• clic droit sur le projet pour lequel on veut ajouter des droits ;
• sélectionner « Team Project Settings » ;
• sélectionner « Security » ;
• sélectionner le groupe ou l'utilisateur pour lequel vous voulez modifier les droits ;
• cliquer sur « Allow » pour le droit à ajouter.

Le build se crée en deux étapes. On passe tout d'abord par un assistant de création pour les étapes les plus basiques puis le paramétrage du build se fera en modifiant le fichier XML produit. (9)

Pour créer un build, il faut impérativement avoir les droits de « Create a Build ».

Pour créer un build :

• aller dans le Team Explorer ;
• clic droit sur le projet pour lequel on veut ajouter un build ;
• sélectionner « Team Builds » et « New Build Definition » ;

• onglet Général

  1. Taper le nom du build et la description ;

• onglet Workspace

  1. Vous avez ici la possibilité de paramétrer le workspace utilisé par le build. Cela a la même signification que pour un développeur et va donc dicter les répertoires du Source Control auquel le mécanisme de build aura accès, et à quel endroit il va les télécharger localement,
  2. Par défaut, aucune modification n'est requise ici ;

• onglet Project File

  1. Un build se base sur un fichier de projet XML, d'extension .proj,
  2. Visual Studio 2008 nous laisse la possibilité de modifier son emplacement,
  3. Nous pouvons nous contenter de l'emplacement par défaut et donc simplement cliquer sur Create,
  4. Visual Studio nous propose alors une fenêtre avec toutes les solutions disponibles dans le workspace que nous avons créé. A vous de cocher les solutions sur lesquelles vous voulez travailler dans le build automatisé, puis cliquer sur Next,

  5. Sélectionner la configuration que vous voulez utiliser pour le build ;

     • configuration : Debug ou Release selon le type de compilation que vous voulez faire ;

     • Platform :

       • .NET pour un site web,
       • x86 pour une DLL,
       • Mixed Platforms pour une solution comportant à la fois un site web et une DLL (10) ;
  6. Cliquez sur « Next » ;
  7. Vous pouvez ici préciser si vous voulez exécuter des tests lors de votre build automatisé. Pour cela, vous pouvez soit vous baser sur des listes de tests (.vsmdi) ou laisser le build découvrir les tests exécutables dans les DLL que vous lui spécifiez ;
  8. Vous pouvez ensuite cliquer sur Finish ;

• onglet Retention Policy

  1. Vous allez lancer de très nombreux builds et ils peuvent prendre beaucoup de place sur le serveur. Cet onglet vous permet de spécifier ce que vous voulez faire de vos builds : tous les garder, les supprimer…
  2. Notez que ce choix va probablement dépendre de la taille de vos builds et de votre propre politique de build ;

• onglet Build Defaults

  1. Choisissez le Build Agent par défaut qui lancera votre build. L'agent est simplement le serveur de build. Ce choix par défaut pourra être « overridé » lors de chaque lancement de build.
  2. Indiquez ensuite le chemin réseau sur lequel vous voulez que les fichiers de votre build soient copiés une fois celui-ci terminé

• onglet Triggers

  1. Vous avez ici la possibilité de paramétrer à quelle fréquence vous voulez que votre build se lance.
  2. Deux choix typiques sont de le lancer chaque nuit, mais également à chaque remontée de code (check-in)

Le build étant composé de deux parties (les éléments introduits dans la fenêtre « Build Definition » et ceux du fichier .proj), l'édition va se faire également à ces deux endroits.

Pour éditer les propriétés générales, il suffira de cliquer droit sur le build en question et de choisir Edit Build Definition pour que l'on puisse changer les valeurs introduites dans ce wizard.

Pour le fichier .proj, on pourra :

• cliquer droit sur le build ;
• cliquer sur View Configuration Folder ;
• une fois la fenêtre du Source Control ouverte, alors on pourra double cliquer sur le fichier .proj pour le modifier.

VIII-C-1. Via VS▲

VIII-C-2. En ligne de commande▲

TFSBuild start TeamFoundationServerName TeamProject BuildTypeName /queue
TFSBuild start svrTFS MyTeamProject "Mon Team Build" /queue

VIII-D-1. Quelques tâches disponibles▲

VIII-D-2. Quels sont les targets que l'on peut overrider▲