Michel Perfetti [Miiitch]

[TFS] C’est le printemps, c’est le moment de faire le ménage!

TFS est un système qui vit au rythme de vos projets, de vos développeurs et de l’évolution de votre parc informatique. Chaque jour apporte son lot de buildq, de workitemq, de fichiers à modifier, etc… A la longue si on y prete pas attention, vous allez commencer à accumuler certains éléments qui peuvent être difficile à gérer a posteriori. Voici donc un petit tour d’horizon du genre de “ménage” qu’il  faut régulièrement effectuer sur TFS.

Gestions des utilisateurs

Plusieurs choses font que la gestion des utilisateurs peut-être problématique:

• vous avez de nouveaux utilisateurs avec des droits spécifiques
• vous avez des developpeurs qui quittent l’usine de développement

Pour le premier point, il ne faut surtout pas se laisser tenter à donner des droits directement au niveau du controleur de source : cela devient vite difficile à gérer. Il faut mieux créer des groupes TFS (par exemple FOO_W et FOO_R) qui eux auront un accès en lecture/écriture ou lecture seulement sur une partie du source par exemple. Sachez une chose: lorsque l’on branche du code, on récupère aussi les droits. Donc si vous avez un nouveau développeur qui doit à la fois travailler sur la main et une branche de release, il faut lui donner 2 fois les droits. Avec un groupe, c’est une seule fois.

Et oui les utilisateurs, ca s’en va et aussi ca revient. Lorsqu’ils s’en vont, il ne faut pas hésiter à les sortir du controleur de source. Là encore si ils sont dans des listes c’est plus simple. Ce qui peut être utile c’est d’avoir des groupes AD pour les développeurs avec de même droits. Cela vous évite de les ajouter dans TFS un par un: dès qu’ils sont dans l’AD, ils ont accès à la plateforme.

Gestion des workspaces et des fichiers, du shelving

Petit rappel: TFS sait tout de vos workspaces:

• la machine
• le mapping
• le compte associés
• les fichiers en éditions
• la date de dernière utilisation

Et tout développeur, aussi bon qu’il soit, laisse sur son passage un ensemble de workspaces totalement inutiles: il suffit de se logguer sur une machine et d’ouvrir le Team explorer: vous avez déjà un workspace: celui qui a le nom de votre machine. Ceux là sont pas dangereux. Les plus dangereux sont ceux que l’on laisse sur des machines qui n’existent plus: par exemple vous changer de machine. Ces workspaces peuvent contenir des fichiers en édition avec des verroux par exemple. Régulièrement regarder les workspaces de vos utilisateurs et détruisez les plus vieux. Il peut aussi avoir des workspaces trop utilisés! Je m’explique: on a tous tendance à laisser traîner des fichiers en édition (j’en ai déjà vu en édition de plus de 2 ans), mais que veux dire qu’un fichier est en édition depuis 1 mois: cela veut dire que la dernière fois qu’il a été archivé remonte au moins au mois dernier. Imaginez ce qu’il se passe si la machine crashe et posez vous aussi la question de ce que vous faite de ce fichier: doit-on ou ne doit-on pas l’archiver?

Il y a le shelving mais là aussi on peut vite se laisser déborder par un nombre de plus en plus importants de fichiers dans des shelveset. Dans les 2 cas, surveillez vos utilisateurs pour qu’il n’abusent pas trop des shelvesets et q'u’ils évitent des fichier en édition sans archivage pendant trop longtemps.

Gestion des builds

La aussi cela peut devenir problématique: si votre logiciel est gros, vous risquez d’accumuler beaucoup de build inutiles (inutiles pour la livraison du soft, et pour les développeurs) et saturer vos dossieurs de partage. Pour éviter cela, vous pouvez jouez sur les options de retention  des builds en décidant de garder qu’un certain nombre d build reussies et en supprimant celle qui ont échoués. Je vous conseille de garder au moins la dernière qui a échouée car sinon des que la build plante elle est détruite et il n’est plus possible d’identifier l’erreur. Détail important, avant TFS 2008 SP1, il n’était pas possible de détruire la build et de garder le label (TFS 2008 SP1, et TFS 2010). N’hesiter par à blocker des builds et à jouer sur la qualité de la build pour indiquez à vos équipes les builds qui peuvent les interesser.

Qu’est-ce qui peut m’aider pour tout cela?

Sans outil tout cela n’est pas possible. Un bon outil est Team Foundation Sidekicks qui va vous permettre:

• d’identifier les fichiers en édition (et aussi supprimer le changement ou le lock)
• d’identifier les vieux workspaces et shelveset
• De vérifier les droits d’un utilisateur

Sinon il y a aussi les API de TFS pour faire tout cela, mais ça vous en parlerez plus tard.

@+