Team Foundation Server Côté utilisateur - Version 1.0
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Team Foundation Server
Côté utilisateur
Version 1.0
Z
Sylvain Lieu
Franck Boisgibault
2 Team Foundation Server Côté utilisateur
Sommaire
1 Accès................................................................................................................................................ 3
1.1 Team Explorer ......................................................................................................................... 3
1.2 Portail web .............................................................................................................................. 3
1.3 Intégration à Microsoft Excel et à Microsoft Project .............................................................. 4
1.3.1 Microsoft Excel ................................................................................................................ 4
1.3.2 Microsoft Project ............................................................................................................. 5
2 Principes de base ............................................................................................................................. 8
3 Versionning.................................................................................................................................... 10
3.1 Fusion des fichiers ................................................................................................................. 10
3.2 Les verrous ............................................................................................................................ 14
3.3 Les historiques de version ..................................................................................................... 15
3.4 Les branches .......................................................................................................................... 17
4 Build ............................................................................................................................................... 19
4.1 Architecture........................................................................................................................... 19
4.2 Agent de build ....................................................................................................................... 20
4.3 Définition de build ................................................................................................................. 21
4.4 Lancement de build ............................................................................................................... 22
4.5 Build Explorer ........................................................................................................................ 23
5 Conclusion ..................................................................................................................................... 26
Dotnet France Association
3 Team Foundation Server Côté utilisateur
1 Accès
1.1 Team Explorer
Team Explorer est un outil additionnel qui s’intègre à Visual Studio pour permettre
l’exploitation de TFS. Il est disponible gratuitement sur le site de Microsoft ou via le dvd d’installation
de TFS.
Il se démarque par sa simplicité d’utilisation et par le nombre de solutions qu’il propose pour
gérer un projet. En effet, son intégration à l’IDE Visual Studio rend sa prise en main naturelle et
intuitive. Il ressemble parfaitement au « solution explorer » utilisé régulièrement par les
développeurs .NET. De plus, par un simple click droit, il est possible d’accéder à la plupart des
fonctionnalités de TFS.
C’est donc l’outil idéal mais il est nécessaire d’avoir au moins un Windows Server 2003 SP1, un
Windows XP SP2 ou un Windows Vista pour l’utiliser.
1.2 Portail web
Le portail web est une alternative multiplateforme à Team Explorer. Il suffit de suivre le
chemin http://nom_du_serveur/sites/nom_du_projet pour y accéder.
Dans le menu de gauche il existe deux rubriques non présentes dans Team Explorer appelées
« Sites » et « Process Guidance ».
- « Sites » permet de créer des sites secondaires destinés aux partages de fichiers, de tâches et
de calendrier. Il sera, ensuite, possible de gérer les permissions pour chacun de ces sites afin
de correspondre au mieux aux différentes sections du projet.
- « Process Guidance » est une aide permettant de mieux appréhender les concepts du travail
collaboratif.
Dotnet France Association
4 Team Foundation Server Côté utilisateur
Nous retrouvons par ailleurs les dossiers « Documents » et « Reports » présents dans Team
Explorer via les rubriques du même nom.
Il est important de noter que les Work Items et la gestion des Builds ne sont pas disponibles
par défaut dans le portail web. Il est cependant possible d’installer des modules supplémentaires tels
que les Power Tool disponibles sur le site de Microsoft qui permettent de combler cette lacune :
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=3ecd00ba-972b-4120-
a8d5-3d38311893de.
Le portail web est donc moins intuitif et moins complet mais il a l’avantage d’être accessible à
partir de toutes les plateformes et ne nécessite pas d’installation.
1.3 Intégration à Microsoft Excel et à Microsoft Project
Team Foundation Server est fait pour faciliter le travail de chacun des intervenants dans un
projet. Certains de ces intervenants ne sont pas des développeurs. C’est le cas par exemple des
managers ou des Assistants de direction. Il peut cependant être utile de les tenir informés de la
productivité et de la disponibilité des développeurs. Afin de leur éviter l’utilisation d’un nouveau
logiciel, Microsoft a décidé d’intégrer l’outil TFS à Microsoft Excel et Microsoft Project.
1.3.1 Microsoft Excel
L’implantation dans Excel est moins poussée que celle dans Microsoft Project mais elle
présente l’avantage d’être disponible sur presque tous les ordinateurs d’une entreprise.
Pour utiliser TFS via Microsoft Excel, il faut d’abord installer Team Explorer. Un nouvel onglet
apparaitra alors dans la barre de menu de Excel 2007 nommé « complément ». Il faudra ensuite
utiliser le menu « Equipe ». Ce menu est accessible directement via la barre de menu sur Excel 2003.
Cliquer sur « nouvelle liste » pour ouvrir la fenêtre de connexion, identique à celle de Team
Explorer. La connexion s’effectue de la même manière qu’avec Team Explorer. Une nouvelle fenêtre
apparait alors dans laquelle il est possible de sélectionner le type de requête que l’on souhaite
afficher. Dans cet exemple, nous choisirons « all tasks » qui permet de gérer les différentes tâches du
projet. Nous parlerons des tâches dans la partie « Création des éléments de travail ».
Un tableau récapitulatif des tâches associées au projet apparait. Les premières tâches sont
toutes créées par défaut au démarrage et varient en fonction du MSF. Dans ce projet, « MSF for Agile
Software Development » avait été utilisé.
Dotnet France Association
5 Team Foundation Server Côté utilisateur
Projet : Dotnet-France Serveur :
10.9.16.14 Requête : All Tasks
Work Item Assigned Completed Remaining
ID Discipline State Rank Title
Type To Work Work
76 Task Active TFSSETUP 0 0 Set up: Set Permissions
77 Task Active TFSSETUP 0 0 Set up: Migration of Source Code
78 Task Active TFSSETUP 0 0 Set up: Migration of Work Items
79 Task Active TFSSETUP 0 0 Set up: Set Check-in Policies
80 Task Active TFSSETUP 0 0 Set up: Configure Build
Set up: Send Mail to Users for
81 Task Active TFSSETUP 0 0
Installation and Getting started
82 Task Requirements Active TFSSETUP 0 0 Create Vision Statement
Set up: Create Project Description
83 Task Active TFSSETUP 0 0
on Team Project Portal
84 Task Requirements Active TFSSETUP 0 0 Create Personas
Project
85 Task Active TFSSETUP 0 0 Define Iteration Length
Management
Create Test Approach Worksheet
86 Task Test Active TFSSETUP 0 0
including Test Thresholds
Brainstorm and Prioritize Scenarios
87 Task Requirements Active TFSSETUP 0 0
List
Brainstorm and Prioritize Quality of
88 Task Requirements Active TFSSETUP 0 0
Service Requirements List
89 Task Active TFSSETUP 0 0 Set up: Create Project Structure
Project
90 Task Active TFSSETUP 0 0 Create Iteration Plan
Management
92 Task Active TFSSETUP 15 59,5 Nouvelle tâche
La dernière tâche a été créée manuellement à partir de Team Explorer. Elle est maintenant
stockée sur TFS et elle est ainsi disponible pour tous les utilisateurs travaillant avec Excel.
Depuis Excel, il est possible de modifier ce tableau et de le publier sur TFS pour le rendre
disponible à toute l’équipe.
Par exemple, admettons que la dernière tâche devienne obsolète. Excel nous permettra de
modifier l’état de celle-ci en changeant simplement le contenu de la case « State ».
Work Item Assigned Completed Remaining
ID Type Discipline State To Rank Work Work Title
92 Task Closed TFSSETUP 15 59,5 Nouvelle tâche
Il suffit ensuite de cliquer sur une case du tableau et de choisir « publier » dans le menu
« Equipe ». En quelques secondes, le contenu est publié sur le serveur et chacun des membres du
projet verra que la tâche est close.
1.3.2 Microsoft Project
L’interface de Microsoft Project est bien plus orientée vers le management d’équipe et offre
donc une bien meilleure solution que Microsoft Excel pour gérer les projets TFS.
Comme pour Excel, il faut d’abord installer Team Explorer avant de pouvoir se connecter à TFS.
La connexion se fait par le menu « Équipe » dans les versions 2003 et 2007. Il faut sélectionner
l’option « Choisir le projet d’équipe » ce qui ouvre une fenêtre d’identification identique à celle de
Microsoft Excel.
Dotnet France Association
6 Team Foundation Server Côté utilisateur
Une fois connecté, les autres options du menu « Equipe » sont disponibles. Il faut cliquer sur
« Obtenir les éléments de travail » pour accéder au contenu du projet d’équipe. Cela ouvre une
nouvelle fenêtre qui permet de sélectionner les éléments de travail désirés.
Ici nous utiliserons la catégorie « My Work Items » afin de voir la tâche que nous avons
précédemment fermée. En effet lorsque la tâche est fermée elle disparait de la catégorie
« All Task » mais reste dans « My Work Items ». Un click sur le bouton « Rechercher »
permet d’afficher les tâches présentes dans cette catégorie. Cliquer sur « OK » pour faire
apparaître les taches dans la feuille de Microsoft Project.
Lorsque les tâches apparaissent dans Microsoft Project, il y a une partie sous forme de tableau
similaire à Excel mais également une partie graphique qui permet de représenter la tâche dans la
durée et de voir son état d’avancement.
Dotnet France Association
7 Team Foundation Server Côté utilisateur
Admettons qu’un manager se rende compte que la tâche fermée précédemment est en fait
utile. Il pourra, de la même façon que dans Excel modifier le contenu de la case « State » pour
réactiver la tâche. Un click sur le bouton « Publier » mettra à jour la base de données de TFS. Par la
suite, nous pourrons retrouver la tâche réactivée dans la catégorie « All Tasks ».
On comprend donc que ces deux logiciels de la suite Microsoft Office n’apportent pas de
fonctionnalités supplémentaires mais ils permettent une très bonne intégration dans les systèmes
informatiques des entreprises. Cela rend le déploiement de TFS plus accessible.
Dotnet France Association
8 Team Foundation Server Côté utilisateur
2 Principes de base
Dans ce cours, ce sera Team Explorer qui sera utilisé. En effet, c’est cette solution qui intègre le
mieux le plus grand nombre de fonctionnalités. Cependant, avant de pouvoir pleinement utiliser
Team Explorer, il est important de connaitre quelques notions.
Tout d’abord, et c’est un comportement étonnant au début, il est impossible de créer un
fichier directement via Team Explorer. Les fichiers doivent être créés à part puis importés dans TFS.
Pour importer un fichier, il faut qu’il soit dans un dossier mappé. Pour cela, il faut aller dans :
Fichier => Contrôle de code source => Espace de travail. Il faut alors éditer son espace de travail
(workspace) et ajouter un nouveau couple [Dossier de contrôle de source – Dossier local]. Les fichiers
présents dans le dossier local pourront être importés.
L’espace de travail (Workspace) est l’endroit sur le disque dur local où sont stockés les fichiers
synchronisés avec le serveur. Il correspond à la somme des dossiers mappés.
Pour mettre sur le serveur les fichiers importés, il faut les archiver (check in). Cela correspond
à l’upload de nos fichiers locaux vers le serveur et se fait via le bouton du menu :
A l’inverse, l’extraction (check out) permet de downloader les fichiers du serveur sur notre
dossier local. Si elle n’est pas effectuée, les fichiers seront tous en lecture seule. L'extraction
s’effectue au click sur le bouton du menu :
Dotnet France Association
9 Team Foundation Server Côté utilisateur
Avant de commencer à travailler sur une source, il est important d’avoir la dernière version. Il
est possible d’obtenir les dernières versions de tous les fichiers en cliquant sur le bouton « obtenir la
dernière version » . S’il n’y a aucun conflit, les versions locales seront alors mises à jour
automatiquement.
Les étiquettes (label) sont utiles également. Ce sont des sortes de marqueurs, qui s’attachent à
une version de fichier. En effet, nous verrons par la suite que le serveur garde les différentes versions
de chaque fichier. Il est parfois difficile de s’y retrouver parmi toutes les versions donc TFS
implémente ce système d’étiquette. Chaque étiquette intègre un nom et une description qui
correspondent au fichier. Nous pourrons par exemple attribuer une étiquette nommé Beta2 décrite
telle que « La seconde version Bêta de l’interface de gestion des factures ».
Dotnet France Association
10 Team Foundation Server Côté utilisateur
3 Versionning
3.1 Fusion des fichiers
Le versionning est probablement la fonctionnalité la plus attendue dans un logiciel de travail
collaboratif. En effet, c’est la gestion des versions qui pose le plus de problèmes si on n’y prête pas
attention. Les chefs de projets attendent donc un produit puissant et efficace qui permettra à
plusieurs développeurs d’agir sur le même fichier.
Dans un projet, plusieurs développeurs peuvent avoir à travailler sur le même fichier (codes
sources, rapports, notes diverses…). Cela pose un problème lors de l’enregistrement car les
modifications de chacun des développeurs seront différentes et un programme standard ne pourra
qu’écraser l’ancienne version. Seules les modifications du dernier développeur seront alors prises en
compte. Cela n’est évidemment pas acceptable et des outils de versionning (contrôle de version)
vont permettre de prendre en compte toutes les modifications.
Pour bénéficier de cet outil dans TFS, il faut mettre les sources dans le dossier « Source
Control ».
Le contrôle des sources va permettre, avant le Check-in, de choisir les modifications à garder
parmi les deux versions (fichier local et fichier sur le serveur).
Il est impossible de créer, à partir de deux utilisateurs différents, deux fichiers ayant un
nom identique et se situant dans le même répertoire. Cependant il sera possible pour deux
utilisateurs d’éditer un même fichier et de l’enregistrer sur le serveur simultanément. C’est à ce
moment là que le contrôle de versions va se mettre en œuvre.
Prenons un exemple. Une classe nommé « Classe Dotnet-France.cs » est créée par Utilisateur1,
il y insère un code qui affiche le texte : « Hello World ! » puis l’archive sur le serveur. Utilisateur2 et
Utilisateur3 récupèrent alors ce fichier et le modifient de la manière suivante :
- Utilisateur2 remplace « Hello World ! » par « Hello Dotnet France ! »
- Utilisateur3 remplace « Hello World ! » par « Bonjour Dotnet France ! »
Utilisateur2 va archiver sa classe modifiée. TFS va détecter que la version sur lequel
l’Utilisateur2 a travaillé est la dernière version disponible et va donc effectuer l’archivage sans
problèmes.
Dotnet France Association11 Team Foundation Server Côté utilisateur
Utilisateur3 souhaite maintenant archiver sa propre version de la classe. Cependant TFS va
détecter que la version la plus à jour (celle de Utilisateur2) n’est pas la version de base d’Utilisateur3.
Il va donc lancer l’utilitaire de résolution de conflits qui proposera plusieurs solutions au problème.
La première fenêtre permet de choisir le fichier à traiter. Dans l’exemple il n’y a que le fichier
« Classe Dotnet-France.cs ». Il est possible d’utiliser l’option « Auto Merge All », qui consiste à
rassembler les deux codes en conflit de manière automatique et, en cas d’échec, il faudra utiliser
l’option « Resolve ».
Dotnet France Association12 Team Foundation Server Côté utilisateur
- « Resolve » propose 4 nouvelles options de résolution de conflits :
- « Merge changes for me » est similaire à « Auto Merge All » et est grisée lorsqu’un confit
impossible à résoudre est détecté.
- « Undo my local changes » permet de garder la version du serveur en supprimant les
modifications que Utilisateur3 a effectué.
- « Discard server changes » permet d’écraser la version du serveur en supprimant les
modifications que Utilisateur2 a effectué. C’est en fait l’inverse de l’option précédente.
- « Merge changes in merge tool » donne la possibilité de modifier manuellement le fichier
grâce à l’interface de fusion.
Après sélection de l’option « Merge changes in merge tool »
Dans notre exemple, une seule ligne (la ligne 10) pose problème. Il est possible de modifier le
code à la main en agissant directement dans la fenêtre du bas. Cependant, TFS propose une
résolution simplifiée en cliquant directement sur la version de la ligne qui nous intéresse.
Dotnet France Association13 Team Foundation Server Côté utilisateur
On peut aussi choisir les deux lignes qui vont alors s’ajouter dans le fichier final.
Une fois les modifications effectuées, cliquer sur OK pour les valider et accepter d’enregistrer
le fichier en cliquant sur « Oui ». Les outils de fusion peuvent alors être fermés et l’archivage doit
être relancé.
Dotnet France Association14 Team Foundation Server Côté utilisateur
3.2 Les verrous
Afin d’éviter cette étape fastidieuse, il est possible d’utiliser des verrous (« lock ») pour
empêcher les autres utilisateurs d’effectuer certaines actions. Il existe plusieurs types de verrous, qui
correspondent à des cas d’utilisation différents. Ils sont mis en place au moment de l’extraction d’un
fichier ou manuellement via Team Explorer.
Dans cet exemple, le projet « Math » sera utilisé. C’est un projet qui fera des opérations simple
telles que l’addition ou la soustraction, et qui renverra le résultat.
En premier lieu, il est possible de verrouiller un dossier ou un fichier via l’arborescence des
fichiers avec Visual Studio. Un click droit sur le dossier à verrouiller puis un click sur le bouton « lock »
ouvrira la fenêtre suivante :
Les deux types de verrous disponibles sont :
- Check out : Permet d’empêcher les utilisateurs d’extraire les fichiers contenus dans le
dossier.
- Check in : Permet d’empêcher les utilisateurs d’archiver les fichiers contenus dans le dossier
mais les autorise à les extraire.
Il est aussi possible d’appliquer un verrou sur un fichier lors de l’extraction de celui-ci.
Voici la fenêtre qui permet de choisir le type de verrou :
Dotnet France Association15 Team Foundation Server Côté utilisateur
Les différents types de verrous sont :
- Unchanged : Permet d’outrepasser un verrou dans le cas où l’utilisateur qui souhaite extraire
le fichier est celui qui a mit le verrou. Le verrouillage sera identique pour les autres utilisateurs.
- None : Ce type de verrou est très similaire au « unchanged » sauf que le verrou sera enlevé,
même pour les autres utilisateurs.
- Check Out : Similaire au Check Out vu précédemment mais ne s’applique qu’au fichier à
extraire.
- Check In : Similaire au Check In vu précédemment mais ne s’applique qu’au fichier à extraire.
3.3 Les historiques de version
A partir du menu contextuel, il est possible d’utiliser trois options d’historique qui permettent
d’assurer le suivi du fichier ou du dossier sélectionné. Ces outils ne permettent pas de modifier
l’élément mais fournit simplement des informations.
- L’option « Afficher l’historique » affiche une nouvelle fenêtre interne au panneau de Visual
Studio. Cette fenêtre contient une liste avec, pour chaque modification effectuée sur le fichier,
un ID, un type de changement et une date de modification ainsi que le nom de l’utilisateur qui
a effectué la modification.
- L’option « Comparer » permet d’ouvrir simultanément deux versions d’un même fichier.
L’utilisation standard se fait généralement entre un fichier local et un fichier sur le serveur
mais ce n’est pas obligatoire.
Pour faciliter la recherche de version à comparer, l'option Compare propose une sélection par
critère via un menu déroulant.
Dotnet France Association16 Team Foundation Server Côté utilisateur
Pour la plupart des types de comparaison, un click sur le bouton *…+ lance une fenêtre qui
permet de rechercher les différentes versions.
o Changeset permet de récupérer une version en fonction de son ID pour pouvoir la
comparer.
Dotnet France Association17 Team Foundation Server Côté utilisateur
o Date permet de récupérer une version sur le serveur à la date indiquée.
o Label permet de récupérer une version en fonction de l’étiquette qui lui a été
attachée.
o Latest Version permet de récupérer la dernière version du serveur.
o Workspace Version permet de comparer le fichier présent dans le workspace
(dossier sur le disque dur) et le fichier que TFS pense avoir. Les versions peuvent
être différentes si on agit directement sur le fichier sans passer par Team Explorer.
Cette manipulation implique de modifier la propriété « lecture seule » du fichier
sur le disque dur.
- L’option « Annoter » lance une fenêtre interne à Visual Studio qui permet de voir l’historique
d’une source en donnant, pour chaque ligne de code, la version, l’utilisateur et la date de la
dernière modification. Contrairement aux deux autres outils présentés, celui-ci est
évidemment indisponible pour les dossiers.
3.4 Les branches
Les branches sont des copies d’un fichier ou d’un dossier qui ont pour but de ne pas modifier
le fichier ou le dossier original. La différence avec une copie simple est que le fichier original
connaitra toutes ses branches. Il sera donc plus facile, lorsqu’il faudra intégrer les modifications, de
réunir les copies en un seul fichier.
Elles peuvent notamment être utilisées pour le développement parallèle. Cela permet de
développer indépendamment les différentes versions d’un même fichier et de les fusionner
seulement à la fin du développement. Cela est un gain de temps lors de l’archivage (un seul conflit de
version) et permet de ne pas utiliser les verrous.
Les branches sont aussi utilisées pour isoler certaines parties du code. Par exemple, une
méthode entière pourra être enlevée dans les branches afin d’être sûr que les développeurs ne la
Dotnet France Association18 Team Foundation Server Côté utilisateur
modifieront pas. Au contraire, on peut aussi ne laisser qu’une méthode dans la branche pour obliger
les développeurs à travailler dessus.
Elles sont également pratiques lorsqu’on veut diffuser une version précise d’un fichier. Ainsi, il
suffira de faire une branche de la version à diffuser et il sera toujours possible de travailler sur le
fichier original.
Cette dernière fonctionnalité est particulièrement utilisée lors de la création de build. En effet,
les builds ont besoin d’avoir des versions fonctionnelles et non modifiées.
Dotnet France Association19 Team Foundation Server Côté utilisateur
4 Build
Le Build est le processus de compilation d’un projet qui permet d’obtenir un exécutable. Dans
TFS, il fait l’objet d’un service spécifique appelé Team Foundation Build, qui utilise les sources
disponibles dans TFS pour générer un exécutable.
Avec cet outil, il sera évidemment possible de compiler le code, mais aussi de le tester et
d’obtenir un rapport détaillé à la fin du processus. Tout cela pourra être partagé avec les autres
développeurs travaillant sur le même projet.
4.1 Architecture
La génération des build s’appuie sur plusieurs fonctions distinctes, qui peuvent être installées
sur plusieurs machines différentes.
Voici un exemple d’architecture possible :
Serveur 2
Serveur 1
Agent de Build
Team
Foundation
Server
PC - Utilisateur
Serveur de
Team Explorer
fichier
Dossier
partagé
1. L’utilisateur se connecte à TFS et réclame un build
2. Le serveur TFS joint le serveur 2 pour générer le build
3. Le serveur 2 dépose le build dans le dossier partagé du serveur de fichier
4. Le serveur TFS obtient le rapport et connait le lien vers le dossier partagé
5. L’utilisateur peut consulter le rapport et récupérer le build
Dotnet France Association20 Team Foundation Server Côté utilisateur
4.2 Agent de build
Avant la création d’un build, il est nécessaire de définir un agent de build dans TFS. C’est un
serveur qui sera chargé d’effectuer les builds et les tests associés. Dans notre cas, l’Agent de Build et
le serveur TFS seront sur la même machine.
Pour définir un agent de Build, il faut cliquer dans le menu « build » puis choisir « Manage
Build Agents ». Une fenêtre s’ouvre alors dans laquelle plusieurs champs peuvent être remplis :
- « Display name »donne un nom à l’agent de build ce qui permettra de le retrouver.
- « Description » permet de décrire l’agent et d’ajouter des informations supplémentaires.
- « Computer Name » correspond au nom de l’ordinateur qui servira d’agent.
- « Communications port » est le numéro du port à utiliser (9191 par défaut).
- « Working Directory » est le répertoire dans lequel le build s’effectuera avant d’être copié
dans le Dossier partagé (définit par l’utilisateur lors de la définition du build). Il faut savoir que
BuildDefinitionPath se transformera en *projet d’equipe+\[nom de la définition du build].
- « Agent status » peut prendre les valeurs : enabled, disabled, unreachable, initializing. Il faut
que le statut soit « enabled » pour pouvoir utiliser l’agent de build.
Dotnet France Association21 Team Foundation Server Côté utilisateur
4.3 Définition de build
Une définition de build permet de choisir la manière dont le build va s’effectuer. Elle permet
de définir l’agent de build, le dossier partagé et le type de compilation à utiliser. C’est le modèle
théorique qui sera suivi lors de la génération d’un build.
Pour créer une nouvelle définition de build, il faut suivre le chemin : build => New Build
Definition.
Les différentes sections à remplir sont :
- General : Il faut entrer un nom et on peut ajouter une description.
- Workspace : Pour ne pas utiliser l’espace de travail par défaut, on peut choisir d’autres
chemins. La colonne « type » permet de définir si le dossier de travail est actif ou masqué, la
colonne « Source Control Folder » permet de donner le chemin du projet sur lequel les builds
seront appliqués et la colonne « Local Folder » définit le chemin du dossier dans lequel le
build sera enregistré.
- Project File : Il faut définir le chemin vers le fichier TFSBuild.proj correspondant à la définition
de build. La plupart du temps, ce fichier est créé dans le dossier du projet.
Si rien n’est trouvé, il faut alors en créer un en cliquant sur le bouton « Create ».
Selections : Cette partie permet de sélectionner le projet pour lequel le fichier
TFSBuild.proj sera créé.
Configurations : Il faut choisir quel type de build va être effectué (release ou debug)
et sous quelle plateforme l’application va être compilée. La plateforme « any CPU »
Dotnet France Association22 Team Foundation Server Côté utilisateur
correspond à toutes les plateformes et « mixed platforms » est utile pour les projets
web.
Options : Trois options sont disponibles dans ce menu. C’est dans cette section qu’il
faut choisir les tests et les analyses de code à effectuer.
- Retention policy : Afin de maintenir la clarté dans l’interface de gestion et l’espace disque du
serveur, il est possible de supprimer les builds selon leurs résultats. Ils sont divisés en quatre
catégories : Echoué, arrêté (manuellement), partiellement réussi et réussi.
- Build defaults : C’est ici que l’agent de build et le dossier de partage sont donnés. Si aucun
agent de build n’a été défini auparavant, il est possible d’en créer un en cliquant sur « New ».
Il est cependant impossible de créer un dossier partagé à partir de cette interface et le
dossier doit donc être défini localement sur le serveur de fichier qui stockera les builds.
- Trigger : Ce menu permet de définir à quel moment les builds seront lancés. Il y a quatre
manières différentes pour effectuer les builds :
La première indique que les builds ne pourront se faire qu’au moment ou l’utilisateur
le demandera explicitement
La seconde va lancer un build à chaque Check-in. Plusieurs build du même projet
pourront être mis en liste d’attente si nécessaire
La troisième ne lancera le build au check-in que si le précédent est terminé. Il ne
pourra y avoir qu’un seul build d’un même projet en file d’attente.
La dernière permet de planifier un build à intervalle régulier.
Une fois la définition de Build effectuée, elle apparaît dans l’arborescence de Team Explorer et
peut ainsi être éditée ou supprimée.
4.4 Lancement de build
Maintenant qu’une définition de build et un agent de build sont créés, il sera possible de
générer un exécutable à partir de TFS.
A partir du menu « Build », cliquer sur « Queue new build » pour afficher la fenêtre ci-
dessous :
Dotnet France Association23 Team Foundation Server Côté utilisateur
A partir de cette fenêtre, on peut :
- Choisir la définition de build à utiliser via le champ « Build definition ». La description
s’affiche alors dans le champ juste en dessous.
- Choisir l’agent de build via le champ « Build agent »
- Choisir le fichier partagé à utiliser via le champ « Drop folder for this build »
- Choisir la priorité via le champ « Priority in queue ». Il y a 5 niveaux de priorité et le champ
« Position » se met à jour en temps réel. Il est possible d’éditer les priorités des build en file
d’attente tant qu’ils ne sont pas en cours de génération.
- Le dernier champ est optionnel et permet de donner des arguments. Cette partie ne sera pas
développée dans ce cours mais Microsoft fournit une documentation claire sur ces arguments :
http://msdn.microsoft.com/en-us/library/ms164311.aspx
4.5 Build Explorer
Build Explorer est l’interface de gestion de la file d’attente et des builds créés. Il conserve les
rapports et permet d’éditer les priorités. Il est également possible de supprimer manuellement ou de
verrouiller les builds générés.
Build Explorer fournit également un système de filtre qui permet de retrouver rapidement un
build spécifique.
L’accès à l’explorateur de builds se fait en cliquant sur « All build definition » dans Team Explorer.
Dans l’exemple suivant, Build Explorer affiche la liste d’attente actuelle. On s’aperçoit que le
second Build à partir de la définition « Build Math » a été ajouté après le build de HelloWorld (10h34)
mais vu que sa priorité est supérieure au build de Hello World, il sera généré avant.
Dotnet France Association24 Team Foundation Server Côté utilisateur
Une fois le build généré, il est transféré dans l’onglet « Completed ». Il est alors possible de
voir les mêmes informations que dans la file d’attente mais aussi de connaître son état (réussi,
partiellement réussi, échoué et arrêté).
Pour obtenir le rapport de build, il suffit alors de cliquer sur le nom du build souhaité et de
nombreuses informations apparaissent. Ces rapports sont utiles pour le debug et pour le suivi.
Dotnet France Association25 Team Foundation Server Côté utilisateur
Il est également notable que les builds peuvent être affichés selon leur définition, leur statut
ou leur agent dans la file. Dans l’onglet « completed », on ne filtre pas par l’agent de build mais par la
date. Ces filtres sont très utiles lorsque de nombreux build sont créés chaque jour pour différents
projets.
On constate ainsi que le service de build a été très poussé afin de répondre au mieux aux
attentes des développeurs. C’est une fonctionnalité indispensable qui a été adaptée au travail
collaboratif, incluant une nouvelle architecture et de nouveaux outils.
Dotnet France Association26 Team Foundation Server Côté utilisateur
5 Conclusion
Nous avons vu comment un développeur peut tirer parti d’une solution telle que TFS. L’accès
est simplifié, le versionning est efficace et le système de build est puissant. Cependant, si cet outil
collaboratif est tant utilisé, ce n’est pas que pour ses performances, c’est aussi pour son adaptabilité
au monde de l’entreprise avec des éléments de suivis du travail, des rôles, des groupes ou encore des
rapports. Tous ces éléments doivent être mis en place par le chef de projet, et ce sera l’objet de la
troisième partie.
Dotnet France AssociationVous pouvez aussi lire
