Michel Perfetti [Miiitch]

Alertes de TFS: what's going on?!

On ne peut pas dire que TFS soit du genre très proactif: lorsqu’on a besoin d’une il faut aller la chercher. Et lors qu’on attend un évènement, il faut généralement consulter TFS pour savoir si cet évènement s’est produit. Et bien c’est ce qu’il se passe si l’on utilise pas le système des alertes: nous allons enfin être informés de ce qu’il se passe!

Les alertes sont composés de 2 éléments principaux:

• Un filtre d’évènement
• Une cible

La cible peut être un email ou un service web maison. L’email permet d’avertir directement un ou plusieurs utilisateurs qu’un évènement s’est produit tandis que le service web inscrit l’évènement dans une sorte de séquence de traitement: d’abord TFS puis un autre service. Les alertes se configurent dans le Alert Explorer (Powertools) dans le menu Team de visual studio. Tous les développeurs peuvent définir leurs propres alertes. Pour pouvoir envoyer des emails, une passerelle SMTP doit être configuré via la console d’administration du serveur.

Voyons ce que l’on peut faire avec l’Alert Explorer. Bien que tout est possible de faire à partir d’une règle vide, TFS contient un certain nombre de règle préremplies. Ces alertes permettent de créer 80% des alertes que l’on souhaite:

Prenons par exemple le cas où un changeset a ignoré les  les politiques de sécurité:

Un filte est aussi simple à faire qu’une requète SQL avec un designer! Le type de sortie (mail ou service web) est géré au niveau du formatage: Html et Text pour email, SOAP pour service web.

Voici quelques exemples d’alertes utiles:

• Lorsqu’un changeset est archivé avec une violation des politiques d’archivage: un mail à l’équipe permet d’informer cette dernière qu’il y a eu du code non identifié ajouté au source,
• Pour surveiller l’utilisation d’un bout du source control: une alerte part lorsque du code est archivé,
• Pour mettre à jour un système externe de remontée d’anomalie: lorsqu’un bug est modifié, un message est envoyé au système externe pour qu’il mettre à jour ses données,
• Pour être informé qu’un workitem vous a été assigné, un mail est toujours utile.
• Indiquer par email le dernier status de la build.

Un point important avec les alertes: il ne faut pas trop en abuser car vous risquer de noyer vos utilisateurs sous des tonnes de mails et ils auront tendance à ne plus les lire! Si vous avez des alertes pour des équipes: éviter de les configurer avec un compte utilisateur qui peut quitter l’équipe: les alertes étant créés par un utilisateur, si vous voulez les modifier par la suite, il faut que vous ayez l’accès aux paramétrage.

@+