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

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


précédentsommairesuivant

9. TFS et Gestion

L'interface offerte par le Team Explorer est parfois limitée. Il y a en effet de nombreuses commandes qui ne sont pas disponibles. Cependant quasiment tout est faisable en ligne de commande via l'outil « tf.exe » disponible sur « %ProgramFiles%/Microsoft Visual Studio 9.0/Common7/IDE ».

Vous trouverez plus d'informations sur cet outil dans la bibliographie « Les différentes possibilités de gestion offertes par « tf.exe » ».

9-1. Quelques commandes utiles

 

9-1-1. Détruire des fichiers dans le Source Control

On peut supprimer des fichiers dans le Source Control, mais le Team Explorer ne nous propose pas de les détruire. Par « détruire », on parle ici d'un équivalent du « Destroy permanently » de Visual Source Safe.

En effet, lorsque l'on supprime un fichier, il est simplement noté comme « Supprimé » dans le Source Control. Si on le détruit, il est physiquement supprimé du Source Control et on ne pourra plus le récupérer.

Détruire un element du Source Control
Sélectionnez
tf destroy $/MyTeamProject/MyItem.cs

9-1-2. Faire un "Undo" sur des fichiers

TFS nous permet de faire un "Undo Check-Out" sur les fichiers sur lesquels nous avons pris la main, autrement dit d'annuler nos modifications locales.

Cependant nous ne pouvons faire ceci via l'interface de Visual Studio que sur les fichiers pour lesquels nous avons fait un « Check-Out » sur la machine courante.

Si nous voulons annuler nos modifications en cours sur une autre machine, nous devons pour cela utiliser une ligne de commande :

Annuler nos modifications en cours sur un element du Source Control
Sélectionnez
tf undo /workspace:MonWorkspace;MonLogin $/MyTeamProject/MyItem.cs

Nous pouvons également utiliser une option « /recursive » de façon à travailler au niveau d'un répertoire.

9-1-3. Lister les fichiers actuellement en Check-Out

Une bonne pratique avant de livrer une version est de vérifier que plus aucun développeur n'a du travail en cours, ou des fichiers « oubliés » sur une machine. Autrement dit, s'assurer qu'il n'y a plus aucun fichier en « Check-Out » qui devrait être remonté sur le serveur.

Pour cela, on peut utiliser la commande « status » :

Lister les fichiers en cours de modification dans le Source Control
Sélectionnez
tf status $/MyTeamProject /recursive /user:*

On peut réduire la recherche à un élément particulier (un répertoire ou un fichier) en précisant le chemin complet de l'élément, et non pas en se contentant d'indiquer le nom du Team Project.

On peut également se restreindre à un utilisateur particulier en remplaçant l'« * » par le login de l'utilisateur.

Notez que l'on peut utiliser une option supplémentaire : « /format:detailed » de façon à obtenir plus d'informations sur les fichiers en check-out :

tf status
Résultat de la comande "tf status" avec un format de sortie

9-2. Présentation de TFS Power Tools

Les commandes de gestion offertes par Visual Studio et le Team Explorer ne sont pas totalement satisfaisantes, et l'utilisation de lignes de commande pour effectuer des tâches quotidiennes peut être pénible. (11)

Il existe cependant un projet Open Source appelé « TFS Power Tools » qui nous permet de compléter cette interface graphique. Cet outil est téléchargeable sur http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx.

Le Team Explorer, avant et après installation des TFS Power Tools
Avant installation Après installation


Quelques avantages que l'on peut lister :

9-2-1. Nouvelles « check-in policies »

Nous n'avons pas abordé le point des « check-in polocies » dans ce document. En quelques mots, cela permet de définir des règles à respecter avant de pouvoir remonter (faire un check-in) des fichiers dans le Source Control. Deux exemples typiques : « ajouter un commentaire lors de la remontée » et « que tous les tests aient été exécutées et soit réussis ».

Pour ajouter une check-in policy, il suffit d'aller dans le Team Explorer et de faire un clic droit sur le Team Project pour sélectionner « Team Project Settings » puis « Source Control ». L'onglet « Check-in Policies » nous permet alors de configurer les policies que l'on veut utiliser sur notre projet.

Comme Visual Studio et le Team Foundation Server sont totalement extensibles, il est également possible de créer vos propres « Check-in Policies ».
Néanmoins, cela nécessite de rentrer dans le modèle objet du TFS, et dépasse donc le cadre de ce document.

9-2-2. Menu contextuel sur les membres d'un Team

Les Power Tools vont également lister les différents membres d'un Team Project. Sur chaque membre, on trouvera un menu contextuel nous offrant les options suivantes :

  • Visualiser la liste des check-in réalisés
  • Visualiser la liste des shelvesets (12)
  • Visualiser la liste des fichiers actuellement en check-out, et ce quel que soit le workspace de la personne

La liste des fichiers en check-out nous permet alors de faire facilement des « Undo » sur ces fichiers, pour autant que l'utilisateur en ait le droit.

9-2-3. Gestion simplifiée des alertes

Il est tout à fait possible dans le Team Foundation Server d'ajouter des alertes, c'est à dire typiquement d'envoyer des mails lorsqu'un événement se produit sur le serveur.

Deux alertes typiques :

  • avertir lorsqu'un build se termine (et qu'il échoue)
  • avertir si un utilisateur fait un check-in de certains fichiers (typiquement s'ils sont impactant pour d'autres utilisateurs

Une alerte se base sur une requête sur différents tables et champs du TFS.

Configuration d'une alerte
Configuration d'une alerte pour avertir si un build échoue

précédentsommairesuivant
Dans la version 2005 de Visual Studio, il n'était pas possible de stopper ou de supprimer un build automatisé en cours d'exécution. L'utilisation de ligne de commandes était donc encore plus fréquente.
Un " shelveset " est un emplacement de stockage isolé pour un utilisateur : il est en effet possible de remonter des parties de code dans le Source Control - afin d'en garantir la pérennité - sans pour autant les inclure dans la solution utilisée par tous les membres de l'équipe.
Ce shelveset peut être visualisé à tout moment par n'importe quel membre de l'équipe, et sur n'importe quel machine. C'est également un des moyens qui peut être utilisé pour faire transiter du code d'un workspace à l'autre.
Il permet également de mettre en pause un développement en cours, de façon à se concentrer sur une autre tâche, sans risque de perdre le travail sur la tâche initiale, ni de polluer les remontées de la deuxième tâche dans le cas où les même fichiers sont impactés.

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.