Création d’une politique d'archivage (check-in) pour Team Foundation Server

Par Florent SANTIN (Winwise) et Daniel TIZON (Winwise)

Sur cette page

Introduction

Conception

Installation

Activation

Exemple concret : politique de vérification de la présence de commentaires

Conclusion

Introduction

Team Foundation Server, le produit serveur de la gamme Visual Studio 2005 Team Suite inclut un contrôleur de sources complètement intégré au processus de développement logiciel défini pour les projets d'équipe. L'une des intégrations les plus visibles est l'association d'un ou plusieurs éléments de travail à un lot de fichiers en attente d'archivage. Cette association permet par exemple d'assigner une modification de code à une tâche de développement ou à la correction d'un bug.
Team Foundation Server permet de rappeler ce type de bonnes pratiques aux développeurs au moment de l'archivage par le mécanisme des "politiques d'archivage".

Team Foundation Server contient de base trois politiques d'archivage qui peuvent être activées à la discrétion du chef de projet :

• Code analysis : vérifie que les règles et conventions de nommage et d'écriture de code sont bien respectées
• Testing policy : vérifie que les tests unitaires ont été exécutés avec succès
• Work Items policy : vérifie qu'un ou plusieurs éléments de travails sont associés au code à archiver

De plus, Team Foundation Server offre un modèle de développement extensible afin de pouvoir compléter cette liste avec des règles supplémentaires...

La librairie « Microsoft.TeamFoundation.VersionControl.Client.dll », présente dans le répertoire « C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\ » contient justement le modèle objet nécessaire à cette implémentation.

Haut de page

Conception

Pour créer sa propre politique d'archivage, il suffit d'un projet de type librairie (une par politique d'archivage), référençant la DLL précédente et d'une classe représentant la logique d’évaluation de la règle.

Deux solutions s’offrent à vous pour la création de cette classe :

• Implémenter les interfaces IPolicyDefinition et IPolicyEvaluation, nécessaires respectivement à la définition de la politique d'archivage et à l’évaluation de la règle avant tout check-in.
  
• Hériter de la classe abstraite « PolicyBase », celle-ci implémentant déjà les deux interfaces précédentes. Cette méthode, plus rapide que la précédente, évite l’implémentation de tous les membres, la plupart étant déjà définis dans cette classe de base.
  

La classe suivante illustre un exemple de politique de Check-in la plus simple possible : Elle se contente d’afficher systématiquement un message d’erreur lors de chaque tentative d'archivage de code dans le contrôleur de sources afin de notifier le développeur que son code comporte des erreurs de validation.

using System;
 using System.Collections.Generic;
 using System.Text;
 using Microsoft.TeamFoundation.VersionControl.Client;
 using System.Windows.Forms;
 using System.Collections;
 
 namespace MaPolitiqueDeCheckin
 {
 [Serializable]
 public class MaPolitique : PolicyBase
 {
 
 public override bool Edit(IPolicyEditArgs policyEditArgs)
 {
 //message (ou formulaire) à afficher lors du paramétrage par l'utilisateur
 MessageBox.Show("edition");
 return true;
 }
 
 public override PolicyFailure[] Evaluate()
 {
 //création d'une liste d'erreurs
 ArrayList changes = new ArrayList();
 //recupération de tout les fichiers en attente de soumission
 PendingChange[] checkedFiles = this.PendingCheckin.PendingChanges.CheckedPendingChanges;
 //parcours de ces fichiers
 foreach (PendingChange change in checkedFiles)
 {
 //vérification sur ces fichiers (par exemple de contenu)
 //en cas de problème, ajout d'erreurs
 PolicyFailure failure = new PolicyFailure("Erreur dans le fichier: " + change.FileName, this);
 changes.Add(failure);
 }
 //renvoie la liste des erreurs pour notification de l'utilisateur
 return (PolicyFailure[])changes.ToArray(typeof(PolicyFailure));
 }

 public override string Type
 {
 get { return "Ma politique de Check-in"; }
 }
 public override string TypeDescription
 {
 get { return "Une description de ma politique de Check-in"; }
 }
 public override string Description
 {
 get { return "Ma Description"; }
 }
 }
 }

Les propriétés « Description », « Type » et « TypeDescription » sont utilisées par Team Foundation afin d’informer les utilisateurs:

• Type représente le nom de la règle
• TypeDescription représente la description affichée lors de l'activation d'une règle d'archivage
• Description représente la description affichée dans la liste des règles activées.

La méthode « Edit » permet de définir dans un formulaire Windows Forms des informations de paramétrage ou de configuration de la règle d'archivage. Lors de l’appel à ce formulaire, il est possible de stocker les informations de configuration directement dans la classe, celle-ci étant par la suite sérialisée sur le serveur Team Foundation afin d’assurer la persistance de ces paramètres et surtout son partage entre tous les utilisateurs devant effectuer un archivage.

A chaque tentative d'archivage des sources, la méthode « Evaluate » est appelée par Visual Studio. Si elle retourne au moins un message d’erreur, le check-in ne sera pas autorisé. La méthode « Evaluate » de chacune des règles actives sera donc exécutée avant chaque check-in.

Haut de page

Installation

Pour être utilisable, une politique de check-in doit être déployée et référencée sur chaque poste de développement. Une fois le déploiement de la DLL fait, il est nécessaire d’ajouter une paire de clé/valeur dans la base de registre au chemin : « My Computer\HKLM\SOFTWARE\Microsoft\VisualStudio\8.0\TeamFoundation\SourceControl\Checkin Policies ».

Cette clé doit avoir le même nom que la DLL (sans l’extension) et comme valeur son chemin complet.

Cet enregistrement dans la base de registre peut bien entendu être automatisé avec un déploiement par un fichier Microsoft Installer (MSI).

Haut de page

Activation

Une fois la politique de check-in installée, il ne reste plus qu’à l’activer sur les différents projets, depuis l’interface de configuration du contrôleur de source.

On remarque ici l’apparition du nom et de la description renseignés dans notre DLL et, lors de la sélection, notre fenêtre de configuration apparaît. Notre politique de check-in est donc maintenant activée.

L’évaluation du respect de notre politique de check-in sera maintenant faite automatiquement dans notre projet. Vu que, dans notre logique, nous avons forcé une erreur, un message apparaîtra pour chaque soumission d’un archivage de fichier au contrôleur de source.

Haut de page

Exemple concret : politique de vérification de la présence de commentaires

Voici un exemple de politique d'archivage configurable capable de vérifier la présence de commentaires sur les classes, méthodes et propriétés de vos fichier *.cs avant toute insertion dans le contrôleur de sources. Pour aller plus loin : http://www.codeplex.com/Wiki/View.aspx?ProjectName=TFSCCPolicy

Haut de page

Conclusion

Cet article vous aura montré les bases de l'implémentation de règles d'archivage personnalisées dans le contrôleur de sources de Team Foundation Server. Les règles d'archivage facilitent l'accompagnement au changement, en particulier dans les phases d'apprentissage et d'appropriation des nouvelles procédures souvent mises en place avec l'arrivée de Team Foundation Server dans les équipes. Notons tout de même que la création de règles d'archivage personnalisées, bien que très utile et tout à fait justifiée, ne représente qu'une infime partie des possibilités de personnalisation de Team Foundation.

Haut de page