Pour la majeur partie des utilisateurs de TFS que j’ai rencontré la fonctionnalité des Alertes joue un rôle important dans leur utilisation de la plateforme ALM de Microsoft et pourtant la plupart ne connaissent que la partie visible de l’iceberg: la fenêtre “standard” affichée lorsque l’on clique sur cet item dans le Team Explorer de Visual Studio:
La fenêtre suivante s’affiche, elle permet de configurer pour plusieurs alertes définies l’envoi d’un email sous forme HTML ou texte à un ou plusieurs destinataires.
La première alerte est en rapport avec les Work Item, la 2ème avec le Source Control et les deux dernière avec l’intégration continue. Ces alertes sont utiles et peuvent être utilisées dans les équipes de taille relativement réduites. Lorsque l’on est dans le contexte d’une grosse équipe, on ne tient pas longtemps face au spam généré par “Anything is checked in” et “Any build completes”. Etre au courant de tout ce qui se passe au niveau du Team Project peut vite s’avérer un enfer qui étant pourtant paver de bonnes intentions! Le besoin s’oriente vite vers la nécessité de réduire le champs d’action des alertes sur un périmètre projet plus restreint et/ou une communauté de gens plus ciblé.
Si la fenêtre précédemment cité est relativement pauvre il faut savoir que ce n’est pas du tout le cas pour le moteur d’alerte de TFS, celui-ci est d’une richesse insoupçonné et ce depuis la version 2005. Pourquoi Microsoft n’expose pas cette richesse directement dans Visual Studio est un mystère pour moi, mais encore une fois, les TFS Power Tools viennent à la rescousse!
L’éditeur d’alertes du TFS Power Tools 2010
Une fois les Power Tools installés vous aurez accès à un nouveau item dans le menu “Team” de Visual Studio 2010 intitulé “Alerts Explorer”.
La fenêtre ci-dessous s’affiche:
Celle-ci est découpée en quatre zones:
- La barre d’outil qui permet de Sauvé les Alertes créées ou modifiées, rafraichir la fenêtre, créer une nouvelle alerte et supprimer une alerte existante.
- La zone de visualisation des alertes existantes pour l’utilisateur.
- La zone de propriétés de l’alerte sélectionnée.
- La zone de définition du filtre de l’alerte.
Les différents types d’alertes
Le moteur d’alerte de TFS gère trois catégories: les Work Item, le Source Control et les Build automatisées. Lorsque l’on créé une nouvelle alerte à partir de l’Alerte Explorer nous avons un nouveau dialogue qui s’affiche:
Les trois catégories sont représentées et l’Alerte Explorer nous propose pas moins de 15 modèles d’alerte.
Il suffira de parcourir les différents modèles pour voir s’il y en a un qui correspond à nos besoins, sinon nous avons toujours la possibilité de créer une alerte avec une définition vide ([Blank Alert]).
Une bonne pratique sera de trouver le modèle qui se rapproche le plus de nos besoin, le choisir puis modifier sa définition.
Avant de valider le dialogue il faudra donner un nom à l’alerte que nous allons créer.
Propriétés de l’alerte
Une fois notre alerte créée/sélectionnée nous pouvons modifier ses propriétés. Le champs “Formatting” nous permet de choisir le mode de livraison de l’alerte, en déroulant cette combo nous pouvons constater qu’il y a un autre mode de livraison que l’envoi d’email!
Les deux premiers choix concernent l’envoie d’email au format HTML ou en texte brut.
Le troisième permettra de configurer l’alerte pour qu’elle exécute une méthode d’un Web Service: très intéressant!
Le champ “Sent To:” devra contenir une ou plusieurs emails si le type d’envoie est “Html” ou “Plaintext” ou l’adresse d’un WebService pour le type “SOAP”.
La définition du filtre de l’alerte
La dernière zone permet de décrire les conditions à remplir pour que l’alerte se déclenche. Cette zone ressemble fort à l’édition d’une WIQL, le meilleur moyen de se familiariser avec l’édition d’une définition est de regarder les différentes définitions générées par les modèles d’alerte.
Vous pouvez ignorer l’onglet “Filter Expression” car il s’agit de la génération du filtre de l’alerte à partir de l’onglet “Alert Definition”, cette valeur ne nous est plus trop utile car tout est géré en interne par l’Alert Explorer.
Bonnes pratiques
Personnellement, j’adore le système d’alerte dans TFS, il permet de fonctionner en mode Push, l’évolution de l’information et les changements de données viendront à vous de manière ponctuelle et quasiment instantanée ce qui améliorera votre réactivité dans l’équipe et fluidifiera les échanges. Il faudra cependant bien définir le périmètre de vos alertes afin de ne pas recevoir 100 emails par jour car ca ne servirait plus à rien!
Quelques conseils en vrac:
- Un chef de projet peut créer une adresse mail de diffusion et enregistrer des alertes pour toute son équipe.
- Afin de s’assurer que la communication est fluide dans son équipe, le chef de projet peut prendre en charge la création des alertes pour les différents membres.
- Utiliser un compte de service pour créer les alertes de tiers (dans le cas précédent par exemple) peut s’avérer pratique. Dans le cas précédent si le chef de projet change, il n’y aura pas de problème pour maintenir les alertes de l’équipe. Les alertes sont rattachées à un compte AD! (et non au destinataire)
- Quand vous êtes le propriétaire d’une librairie, vous pouvez créer une alerte de type “Check-In to a specific folder happens” sur le répertoire de la librairie en question dans le Source Control pour être au courant des modifications par de tierce personnes.
Plus d’info sur la MSDN
C’est ici!
Profiles
