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

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


précédentsommairesuivant

VII. Introduction à Team Foundation Server (TFS)

VII-A. Présentation rapide des possibilités du Team Foundation Server

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.

VII-B. Présentation des différents serveurs entrant en jeu

Architecture Intégration Continue



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

VII-C. TFS et Gestion des Droits d'Accès

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.

La gestion des droits dans le TFS est complexe, car elle concerne :
- les droits sur le serveur ;
- les droits sur un Team Project ;
- les droits sur le source control ou sur un fichier / répertoire spécifique.
Ces différents niveaux de sécurité vont donc être paramétrables à différents endroits (via les propriétés du Team Project, via le Source Control…) et il n'existe pour le moment aucune gestion centralisée possible

VIII. TFS et Intégration Continue

VIII-A. Créer un build

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)

VIII-B. Éditer un build

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.

Attention : la fenêtre de Build Definition se sauvegarde directement en base de données. Par conséquent, chaque modification sera immédiate et prise en compte dans le build suivant.
En revanche, le fichier .proj, est un fichier du Source Control comme les autres, et on devra donc faire un « check-in » avant que ses modifications soient effectives.
Il est important de prendre en compte cette différence de façon à synchroniser sa façon de travailler avec les builds automatisés que l'on veut lancer.

VIII-C. Exécuter un build

VIII-C-1. Via VS

Il y a deux façons d'exécuter un build : de façon graphique ou en ligne de commande.

  • Aller dans le Team Explorer.
  • Ouvrir le nœud du Team Project souhaité.
  • Ouvrir le nœud « Team Builds ».
  • Soit

    • cliquer droit sur le build souhaité ;
    • cliquer sur « Queue New Build ».
  • Soit

    • bouble cliquer sur le build souhaité. La liste des différents builds déjà réalisés est alors affichée ;
    • cliquer sur l'icône Build en haut à gauche de la fenêtre.
  • On aura alors la possibilité de changer l'agent (ie le build server) qui va lancer le build, sa priorité, et l'emplacement de copie une fois le build terminé.
  • Cliquer sur « Queue ».

VIII-C-2. En ligne de commande

Les builds sont en fait exécutés par l'outil TFSBuild.exe. Cet outil fera en interne appel à MsBuild.

TFSBuild se trouve dans le répertoire « %ProgramFiles%/Microsoft Visual Studio 9.0/Common7/IDE ».

TFSBuild : Lancer un build
Sélectionnez
TFSBuild start TeamFoundationServerName TeamProject BuildTypeName /queue
TFSBuild start svrTFS MyTeamProject "Mon Team Build" /queue

L'option « /queue » est optionnelle, mais permet de rendre la commande non bloquante, en insérant le build à lancer dans la queue des builds, comme cela peut être fait lorsque l'on passe par l'interface graphique.

Dans l'exemple, nous demandons l'exécution d'un build - nommé « Mon Team Build » - du Team Project « MyTeamProject », et ce sur le serveur « svrTFS ».

VIII-D. Paramétrer un build

VIII-D-1. Quelques tâches disponibles

Le framework .NET 3.5 vient déjà avec quelques tâches prédéfinies : il s'agit des tâches disponibles dans la DLL Microsoft.Build.Tasks ou dans Microsoft.Build.Tasks selon la version que vous utilisez.

Cependant le fait de travailler avec le Team Foundation Server met à notre disposition d'autres DLL et d'autres tâches, spécialisées dans l'intégration continue.

VIII-D-1-a. Microsoft.Build.Tasks

MsBuild est déjà livré avec un certain nombre de tâches par défaut. Pour connaître la liste complète, veuillez visiter la bibliographie « Liste des tâches fournies dans Microsoft.Build.Tasks ».

On peut cependant lister quelques-unes des tâches qui seront utilisées le plus souvent :

Liste des tâches principales disponibles dans le Framework

Tâche

Description

AspNetCompiler

Va précompiler un site web

Copy

Copie de fichiers dans le système de fichiers

CreateItem
CreateProperty

Création d'Item et de Property

Csc
Vbc

Compilation de projets C# et VB.NET

Delete

Suppression de fichiers dans le système de fichiers

Exec

Exécution d'une action en ligne de commande

GetFrameworkPath

Retourne le chemin d'installation du framework (pour lequel cette version de MsBuild a été buildée)

MakeDir
RemoveDir

Création et Suppression de répertoires dans le système de fichiers

VIII-D-1-b. Tâches liées au TFS

On peut entre autres citer deux DLL qui contiennent des tâches liées à l'intégration continue : « Microsoft.TeamFoundation.Build.Tasks.dll » et « Microsoft.TeamFoundation. Build.Tasks.VersionControl.dll ».

On peut cependant lister quelques-unes des tâches qui seront utilisées le plus souvent :

Liste des principales tâches liées au Source Control

Tâche

Description

Get

Effectue un téléchargement des sources du Source Control dans le répertoire du Workspace courant

Label

Met un label sur certaines sources du Source Control

CreateWorkspaceTask
DeleteWorkspaceTask

Crée (ou supprime) un workspace dans le TFS pour l'utilisateur courant

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

Lorsque l'on crée un nouveau Build, tout le processus de récupération des sources, compilation, test… est déjà prévu par le TFS.

Pour cela, le fichier de build que nous allons créer importe un fichier de Visual Studio : « Microsoft.TeamFoundation.Build.targets », fichier qui se trouve dans le répertoire « %ProgramFiles%\MSBuild\Microsoft\VisualStudio\TeamBuild ».

Ce fichier décrit l'intégralité du Workflow de build et propose des « zones d'accrochage », autrement dit, des emplacements de paramétrage du fichier afin de nous laisser le plus de liberté possible pour notre build.

Vous trouverez ci-dessous le workflow complet qui est exécuté dans le build, avec le nom de tous les targets qui sont appelés. En gras sont notés les targets vides qui sont explicitement prévus comme zones d'accroche.

  • CanonicalizePaths
  • EndToEndIteration

    1. CheckSettingsForEndToEndIteration
    2. InitializeBuildProperties
    3. BeforeEndToEndIteration
    4. BuildNumberOverrideTarget
    5. InitializeEndToEndIteration
    6. InitializeWorkspace

      1. BeforeInitializeWorkspace
      2. CoreInitializeWorkspace
      3. AfterInitializeWorkspace
    7. TeamBuild

      1. CleanAll

        1. BeforeClean
        2. CoreCleanAll
        3. AfterClean
      2. InitializeBuild
      3. PreBuild

        1. Get

          • BeforeGet
          • CoreGet
          • AfterGet
        2. Label

          • BeforeLabel
          • CoreLabel
          • AfterLabel
      4. CleanCompilationOutput

        1. BeforeClean
        2. CallClean
        3. AfterClean
      5. Compile

        1. BeforeCompile
        2. CallCompile
        3. AfterCompile
      6. PostBuild

        1. GetChangesetsAndUpdateWorkItems

          • BeforeGetChangesetsAndUpdateWorkItems
          • CoreGetChangesetsAndUpdateWorkItems
          • AfterGetChangesetsAndUpdateWorkItems
      7. Test

        1. BeforeTest
        2. CoreTest
        3. AfterTest
      8. GenerateDocumentation
      9. PackageBinaries
    8. DropBuild

      1. BeforeDropBuild
      2. CoreDropBuild
      3. AfterDropBuild
    9. AfterEndToEndIteration

Il est également tout à fait possible de redéfinir un des autres targets si l'on décide de se passer totalement d'un comportement standard. Par exemple si l'on décide de faire nous-mêmes la récupération des sources dans le Source Control, alors on décidera de redéfinir le target Get ou CoreGet.

Notez cependant que le workflow est très ouvert et que chaque tâche est hautement configurable en fonction des propriétés ou des items déclarés dans le fichier. Il peut être plus facile de changer une simple propriété que de réécrire un target.


précédentsommairesuivant
Notez que Visual Studio 2010 se basera sur Windows Workflow Foundation et nous permettra donc d'utiliser un éditeur graphique pour paramétrer les différentes « activités » de notre build automatisé.
Notez que d'autres types de configuration existent, mais ne seront cependant pas décrits dans ce document.

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.