Michel Perfetti [Miiitch]

Je déménage!

Après 4 ans et demi passés ici, je change d’adresse. je laisse mes anciens billets ici; vous pouvez maintenant me retrouver sur http://www.buildmeimfamous.net . Merci à toute l’équipe de Codes-Sources pour cette superbe plateforme.

@ Bientot,

Michel

Fissum 1.0.1 avec déploiment ClickOnce

Cette version corrige en particulier le fait que Fissum n’affichait pas les mêmes projets que le TeamExplorer. C’est maintenant corrigé. Il est aussi possible dans cette version d’installer Fissum par ClickOnce. Bon téléchargement!

http://fissum.codeplex.com/releases/view/67671

End Of Line

Bien connaître le fonctionnement des fichiers projets C# et VB.Net pour mieux contrôler la sortie des builds – Episode 1

L’intérêt d’une build est de fournit un binaire compilé toujours avec le même environement, mais la build utilise quand même la configuration qui se trouve dans les fichiers projets. Un exemple: rien n’empêche un développeur de supprimer en mode Release la génération des symboles de debuggage:

Et dans ce cas là la sortie de la compilation devient un peu vide:

Si il n’y a pas de validation à la compilation de la build de la présence des fichiers de symboles, en cas de problème en production, nous n’aurions rien pour nous aider. C’est pour cela qu’il est très important de redefinir au moment de la build la façon dont le logiciel est compilé.  Il y a toujours moyen de modifier avant la compilation la configuration du projet, mais je préfère faire croire à MSBuild que la configuration à compiler est la mienne plutot que de modifier des fichiers.

Avant tout, qu’il y a-t-il dans les fichiers .csproj et .vbproj? Déjà, ce sont des fichiers lisibles par MSBuild. D’ailleurs vous pouvez lancer une compilation pour l’importe quel fichier de projet (ou solution) via la ligne de commande de msbuild. Pour simplifier, on peut assimiler le .*proj à l’ADN du projet.

A la fin du projet, une ligne est très importante:

C’est cette ligne qui va injecter les “targets” MSBuild qui vont compiler le projet. La cible finale, le chef d’orchestre de la compilation, est chargé après par les fichiers spécifiques à chaque langage. Ce fichier est Microsoft.Common.targets.La connaissance de Microsoft.Common.targets est indispensable si l’on veut maitriser la sortie de la build.

Seule la partie bleue est spécifique au projet.

Comment va-t-on faire pour changer le fonctionnement de la compilation? Microsoft.Common.targets contient des points d’extensions qui vont nous permettre de modifier le comportement de la build:

• Un point d’extension avant le chargement des “targets” communes de compilation: ici il va être possible de changer la configuration du projet,
• Un point d’extension après le chargement des “targets” communes de compilation: ici on va pouvoir redefinir des “targets” de compilation pour ajouter nos éléments.

Pour simplifier, ces points d’extensions injectent tout simplement des scripts MSBuild via des <Import /> dans le script du projet. Dans cet exemple, nous allons donc nous comporter comme un virus en injectant notre ADN de compilation: la configuration de la génération des symboles de debug. Voici la configuration en mode Release de notre projet:

Nous allons simplement créer un fichier .target qui contient un “PropertyGroup” avec la propriété “DebugType” à “pdbonly”:

Et nous lançons tout cela via la ligne de commande suivante:

msbuild MonApp.sln /p:CustomBeforeMicrosoftCommonTargets=D:\TempDev\MonApp\ConfigOverride.targets /p:Configuration=Release

Comme attendu les symboles sont maintenant disponibles:

Pour l’instant rien n’est vraiment automatisé, mais nous verrons dans un prochain billet comment mettre tout cela en place dans une build. Pour information, sur TFS 2008 un autre fichier MSBuild est bon à connaître (par coeur): celui de TeamBuild. Dans TFS 2010 il a été remplacé par un workflow en XAML.

End Of Line

Un contrôleur de source, ce n’est pas un simple système de fichiers!

Cela peut sembler évident, mais tout le monde n’est pas sensibilisé à cela: toute opération sur une branche va se répercuter sur les branches parentes lors des merges. Il faut donc, lorsque l’on réalise une opération dans une branche, penser que cela aura des répercutions bien plus tard!

Il n’oublie jamais!

Voici un exemple (vécu):

Gérard est un développeur de l’équipe, on lui a assigné un bug le #567 sur l’application App_X qui est dans la release R3 du soft. Jusque là: rien d’anormal. Gérard tire une branche de toute la release pour réaliser sa correction, y compris App_Y qui n’a rien à voir avec le bug.

Gérard ce dit que c’est idiot de voir pour la correction les 2 projets. On va alors croire que la correction est à la fois dans App_X et App_Y. Gérard décide alors de supprimer App_Y dans sa branche: simple “nettoyage”. Gérard choisit donc d’effectuer un “delete” sur App_Y:

Cela donne alors cet état:

Tout a l’air OK comme cela. Gérard corrige le bug et merge dans la release. Et là, c’est le drame:

Comme je le disais au début: TFS (comme toute contrôleur de source) n’oublie rien. Le delete n’était pas la solution (le “delete” n’est généralement pas la bonne décision!). Qu’aurait du faire Gérard?

Déjà Gérard aurait du avoir l’option suivante activée:

Il aurait alors vu que le dossier était marqué comme supprimé dans TFS. Cela lui aurait surement mis la puce à l’oreille:

Gérard avait en fait 2 options:

• ne rien faire (des fois c’est la meilleur des options): pour une branche le plus important ce ne sont pas les fichiers que l’on a branché, mais ce qu’il y a dans l’historique.
• demander une destruction du projet dans sa branche: contrairement au “delete” qui crée une opération pour supprimer des fichiers. La destruction de fichiers fait comme si les fichiers détruits n’avaient jamais existé, donc aucun historique!

Cela ce passe en ligne de commande:

Et donc au moment du “merge”: aucune opération d’effacement est crée:

Contrairement à un “delete”, le “destroy” est irréversible et est réservé que dans ces cas exceptionnels. De même un “delete” doit rester rare: supprimer un fichier revient à supprimer du code, donc supprimer de la valeur et surtout perdre l’historique. Cela est d’autant plus vrai pour un projet complet. Il est plus interessant de créer un dossier spécifique qui recevra l’ensemble des projets décommissionnés plutot que de les détruire et de marquer ce dossier en lecture seule.

Alors comment identifier ces changesets qui peuvent contenir ce genre d’opérations. Généralement je les retrouve avec les commentaires suivants: “cleaning”, “refactoring”…  et tout ce qui peut induire des changements dans la structure du code.

Bonne chasse!

End of line

Pourquoi il est important de bien choisir son workspace lors d’une build

Le workspace d’une build est le passage obligé lors de sa création. SI il est mal fait, la build ne pourra pas être utilisée à 100% de ses capacités.

Prenons un exemple avec le source suivant:

Il y a 2 applications: App_X et App_Y. J’ai configuré 2 builds quasiment identiques pour App_X:

Ces 2 builds ont que leurs workspaces de different:

Ces 2 builds feront exactement la même chose tant qu’elles seront lancées manuellement. Une première différence peut apparaître au lancement car la build possède la tâche suivante:

S’il y a beaucoup de fichiers, la première build sera donc plus longue et surtout si un label est posé, il le sera sur tout le source: ce qui ne sera pas très pratique lorsque l’on voudra récupérer  le source de App_X posé sur cette build: on récupérera aussi celui de App_Y! Imaginons maintenant que l’on veuille que les builds soient en mode intégration continue, c’est à dire qu’à chaque check-in du projet la build se lance. Les 2 builds vont avoir un comportement différent.

C’est pas magique: la seule façon  de savoir quelle build doit être lancée à chaque check-in et de confronter les fichiers du changeset, et les workspaces des builds. Si un des fichiers est compatible avec le workspace de la build, cette build est lancée. Modifions maintenant un fichier du projet App_Y. Il se passe la chose suivante: la build App_X est activée alors que l’on n’a pas du tout modifié le project App_X et la build App_X_2 n’est bien sur pas lancée:

Ces quelques secondes passées à la définition du workspace font donc toute la différence!

End of line

Branches, bugs, et chef de projet! Ou comment faire voyager les changesets dans le contrôleur de source sans faire de “baseless merge”.

Voici la situation: Bob bosse sur un bug de la version R1 du soft, la correction est prète mais le chef de projet décide que ce bug ne sera pas corrigé dans la V1: la V2 est déjà sorti, et  il ne veux plus que des corrections de sécurité sur la V1. Par contre le bug existe dans la version en cours de développement, il faut donc corriger cette version.

Voici une image du contrôleur de source:

Si c’était possible, il faudrait faire un merge entre la branche R1-BUG_345 et la Main. Mais ce n’est possible qu’en mode baseless (Let me google that for you ). Mais cette opération n’est pas forcément la plus simple car elle n’utilise pas les informations que TFS possède sur l’origine des fichiers: il est tout à fait possible qu’entre la R1 et la Main actuelle, les fichiers qu’il faut fusionner aient été renommés ou déplacés, et là, le baseless merge ne vas pas trop nous aider. Autre possibilité: utiliser le merge de TFS tout en compensant: nous allons effectuer 2 merges jusqu’à la main et ensuite faire en sorte d’annuler nos modifications dans R1 et surtout acter cette modification dans la Main. Pour cela nous allons utiliser la ligne de commande de TFS 2010 (la fonction était dans les powertools dans les versions précédèntes).

Dans Visual Studio j’effecture les opérations suivantes:

• merge R1-BUG_345 –> R1: changeset 22
• merge R1 –> Main du changeset 22 : changeset 23

Maintenant nous avons notre correction dans la main. Il ne reste plus qu’à la supprimer de la branche R1. Pour cela nous allons donc utiliser la commande “tf rollback”:

tf rollback /changeset:C22~C22 /recursive /keepmergehistory

Voici l’état des pending changes:

On remarque bien que l’état est “Rollback”! Regardons l’historique du fichier en question:

J’ai ajouté l’option /keekmergehistory pour indiquer à TFS que je ne veux plus que le changeset 22 soit appliqué si je remerge la branche R1-BUG_345 dans R1.

On pourrait penser que tout est bon maintenant, mais il manque une étape: si je merge la branche R1 dans la Main, le code va être annulé comme dans R1! Il y a maintenant 2 possibilités pour corriger cela:

• Solution 1: faire le merge dans la main et refaire un rollback avec l’option /keepmergehistory: 2 opérations
• Solution 2: faire croire que le merge de R1  vers Main est effectué via un /discard dans le merge: 1 opération.

Prenons la solution 2: tf merge /recursive /discard /version:C24 “$/MSF Agile Test/Release/R1” "$/MSF Agile Test/Main”

Historique devient comme suit:

Les commentaires sont importants pour bien comprendre ce qui s’est passé.

Nous avons donc réussi notre mission: Rien dans R1 et le bug corrigé dans la Main. Un conseil pour ces opérations: travailler si possible sur un seul changeset à la fois ou un groupe de changetset assez proche de la latest d’une branche: cela vous évitera les conflits pour la résolution du code.

J’ai utilisé l’option /keekmergehistory, mais sans cette option le rollback est très utile pour:

• un développeur:  pour annuler un changeset un peut trop rapidement fait,
• pour un gestionnaire de l’usine: pour annuler un changeset qui fait planter la build si le développeur ne peux pas corriger de suite: c’est un peu notre arme anti-plantage de build .

End Of Line

[TFS] Qui a dit que la build compilait toujours la dernière version?

L’affirmation qui dit que la build compile toujours la dernière version est ni vrai ni fausse, juste incomplète: la build ne compile pas la dernière version du code au moment où la build récupère le code, mais au moment où elle démarre. Cela fait toute la différence et c’est tant mieux en fait!

Démonstration:

Je prends un projet dans l’état suivant: avant la build le dernier changeset archivé est le #13. Je lance la build. Remarquez quelle version est prise:

On en apprend pas beaucoup à ce moment là.

A ce moment même, j’archive un bout de code: c’est le changeset #14. La build a continué de son coté et son status changé entretemps:

La build ne prend pas en compte ce changeset et s’arrète au #13!

Explication:

Voilà ce qu’il s’est passé: avant que j’archive le changeset #14, la build a déterminé que le dernier changeset correspondant à la “Latest” était le #13. Donc quelque soient les nouveaux changesets créés, la version du source qui sera utilisée pour la build sera la dernière version jusqu’au changeset# 13. Donc mon changeset #14 n’est pas pris en compte. Cela est très utile pour plusieurs cas:

• Imaginons une build avec 2 solutions: A et B. si la build commence à compiler la “latest” pour A puis la “latest” pour B si peut y avoir potentiellement un soucis si par exemple la “latest” de B prend en compte un changeset qui comprend des modifications de A ainsi que des modifications de B qui ont besoin des modifications de A. Le résultat est un plantage de la build. Pourtant lorsqu’on récupère la dernière version du code: tout marche!
• Avec ce numéro de changeset la build peut être relancée plusieurs fois avec le même code source (changeset ou label). Pour cela il suffit d’aller dans les propriétés avancées lors du lancement de la build:

Build me baby one more time!

Un tout petit détail: et bien en fait cela ne marche pas! Il faut modifier le template de build car celui par défaut ignore complètement cette propriété. Pour cela, j’ai ajouté la tâche suivante dans le workflow:

Elle est ajoutée dans la séquence “Run On Agent” et la tâche SetBuildProperties a les propriétées suivantes:

Avec tout cela la version compilée par vos builds n’aura plus de secrets pour vous!

End Of Line

Gource, vous connaissez?

On reste quand même dans TFS dans ce billet mais au travers d’un outil plutot surprenant: Gource. Gource est un système de visualisation de l’évolution du code source dans le temps:

Chaque branche noeud est un répertoire et chaque point est un fichier lors d’un check-in. On a aussi la possibilité de voir les utilisateurs naviger entre les différents check-in. Gource produit une video à partir d’un log. Le format de log est très facile à produire, mais il y aussi un petit projet pour cela.

A part le coté ludique de la chose, je trouve que Gource apporte 2 dimensions à l’historique assez interessantes:

• L’espace: un gros check-in apporte enormement de points à l’écran et cela est tout de suite visible. En plus on peut revenir en arrière et voir qui a fait cette opération et où elle se produit. De plus si certaines parties du logiciel ont été modifiées et qu’elles n’auraient pas du ou pas autant, cela aussi est visible de suite.
• Le temps: la video permet d’identifier les périodes “mortes” dans l’utilisation du controleur de source, et surtout d’identifier les périodes à forte activité. Par exemple si à deux jour d’une livraison ou de la fin d’un sprint, le nombre de check-in s’accélère, c’est peut-être des ennuis en persceptive. Il faut donc peut-être penser à revoir le rythme des builds et à surveiller la qualité du code qui est ajouté.

@+

[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.

@+

[TFS] Mise sur étagère: “I’m a shelf for you”

Il faut le dire: la mise sur étagère ou “shelving” n’est pas la fonction la plus connue de TFS. Et pourtant on l’a déjà vu, elle peut être très utile. Voic un tour d’horizon de ce que l’on peut faire avec cette fonction. Voila comment cela marche: la mise sur étagère sauvegarde vos fichier en édition (d’un workspace) sur le serveur, sans faire de check-in!  Faire du shelving, c’est aussi simple (voire même plus) qu’un check-in. Pour réaliser une mise sur étagère ou récupérer du code mis de coté de cette façon, il suffit d’aller ici:

Lorsque je clique sur “Shelve”, j’obtiens cette fenêtre:

C’est là que le shelving est différent du check-in: nous avons la possibilité, une fois le shelveset créé, d’annuler automatiquement les modifications en cours! Nous allons y revenir un peu plus loin.

Regardons l’opération inverse:

On remarques quelques éléments intéressants:

• Un peu utiliser un shelveset d’une autre personne,
• On peut avoir plusieurs shelvesets,
• Derrière le bouton “Details…”, on a la possibilité de corrigurer l’option d’un shelveset avec par exemple la possibilité de l’effacer une fois la récupération effectuée.

Voici quelques informations importantes à connaître pour cette opération de restauration d’un shelveset:

• Il vaut mieux ne pas avoir de fichier en check-out car “unshelve” ne peux pas faire de merge
• Les fichiers sont restaurés avec  comme version courante celle qui était utilisé par le fichier lors du shelving (normal finalement). Ce qui veut dire que vous aller avoir des fichiers en édition mais qui ne sont pas associés à la latest: donc attention lors de la compilation, un “get latest” est nécessaire pour faire le merge puis le check-in (dans cet ordre c’est plus simple):

Alors que faire de cette fonctionnalité?

• S’en servir pour passer du code à une autre personne lors d’un développement à plusieurs,
• Sauvegarder son travail régulièrement sans avoir à faire de check-in: par exemple un shelveset par jour. Via la ligne de commande de TFS, il est possible de programmer le planificateur de tâche pour faire le boulot pour nous:  par exemple  une mise sur étagère appellé “sauvegarde du soir” sera automatiquement remplacée au jour le jour:  si au moment du shelving, un shelveset existe déjà avec le même nom il sera remplacé,
• Vous être en train de travailler et un incident urgent apparait. Au lieu d’annuler le code ou pire faire un check-in d’un code à moitié terminé, le shelving nous permettra de revenir en arrière le temps de la correction,
• Plus rien ne marche, et vous voulez revenir en arrière pour voir si le comportement est le même avant que vous décidiez “d’optimiser les algos”  sans perdre vous modifications.

Il n’est pas possible directement avec le Team Explorer de restaurer du code mise sur étagère dans une autre branche, mais les power tools via la ligne de commande “tpft unshelve /migrate” le gèrent. Un dernière point: comme le shelveset est lié à une version spécifique du code, plus on attend pour le restaurer, plus il devient compliqué de le faire, un peu comme une vieille branche que l’on oublie de merger.

@+

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.

@+

Le “Check In” sans règles: Highway to #fail!

Un changeset répond à plusieurs questions:

• le “Qui”: l’auteur du checkin,
• le “Quand”: la date,
• le “Comment”: le code qui est ajouté au controleur de source,
• le “Où”: l’emplacement dans le controleur de source,
• le “Pourquoi”: le commentaire et les work-items associés.

Les 4 premières sont systématiquement connues car elles sont les éléments essentiels d’un changeset. Par contre le “Pourquoi” dépend du bon vouloir du développeur. Et souvent après plusieurs heures de code, le développeur, n’est pas très bavard: mais nous avons les moyens de les faire parler!

Plus globalement, nous allons nous servir du moment du check-in pour valider certaines choses relatives au futur code. Pour cela nous sommes aidés des politiques de check-in. Elles se configurent au niveau du paramétrage du controleur de source d’un projet. Certaines sont installées avec les power tools de TFS dont je recommande vivement l’installation:

Pourquoi ce “check in”?

Première utilité: améliorer la traçabilité du code. Si l’on ne sait pas pourquoi du code a été ajouté, il devient difficile de déterminer vers quoi évolue le logiciel. Il est donc important d’avoir au moins un commentaire lors du check-in et aussi un work item. Pour cela nous alons utiliser le “Changeset comments policy” et soit le “Work Items” policy ou “Work Item Query Policy”.

La “Work Items” policy oblige le développeur à définir au moyen un work item tandis que la “Work Item Query Policy” oblige le développeur à en choisir au moyen 1 dans une requète (généralement quelque chose dans le genre de “Mes tâches”). Dans les 2 cas il est toujours possible de corriger le changeset a posteriori en mettant à jour le commentaire via la fenètre d’historique et via un workitem de le lier au changeset.

Amélioration de la qualité du code

Il est aussi possible de valider l’analyse statique du code sur certaines règles (cela a l’effet de bord intéressant de vérifier que le code compile)  ou que certains tests passent (même si théoriquement cela a été validé avant). On peut voir ces politiques de “check in” comme des pense-bêtes pour les développeurs.

Et si on ne joue pas le jeu?

Si l’on suit les règles tout ce passe bien, mais que ce passe-t-il si on ne les respecte pas ? Dans la fenètre des fichiers en attente d’archivage, des erreurs apparaissent:

Il suffit de les corriger ensuite pour que tout rentre dans l’ordre. Mais quelque fois ce n’est pas possible de toujours respecter les règles (à part le commentaire de check-in bien sur!), et il n’est pas concevable d’empécher un développeur d’archiver du code. Par contre si cela est obligatoire, le changeset sera marqué comme violant les politiques de check-in.

Voila ce qu’il se passe au moment du check-in avec des règles en echec:

Et là pas le choix, il faut mettre un commentaire pour pouvoir archiver.

Conclusion

Ces règles sont d’une grande utilitée mais il ne faut pas en abuser. Quand il y en a une ça va, mais c’est quand il n’y en a plusieurs que cela pose des problèmes:

• par exemple il faut toujours que le développeur ait  un workitem à ajouter et, dans certains cas, ce n’est pas lui qui les créent: même si il sait quoi faire, il faut qu’il puisse le signifier dans le code!
• si la validation prend trop de temps: analyse statique trop longue ou tests trop longs, le développeur aura tendance à contourner les poliques de check-in.

Il faut donc trouver un compromis pour que tout le monde sorte gagnant!  Pour terminer je précise que je n’ai pas parlé ici de toutes les politiques de check-in que fournit Microsoft. Il y en a bien évidemment d’autres: ce sont de simples dll à créer en C# ou VB.Net mais il faut qu’elles soient déployées sur tous les postes.

@+

Michel

500 Checkins sur la ligne de départ!

Dans un logiciel complexe lors de la phase de développement, on n’a pas toujours le même niveau de tolérance aux erreurs en fonction de la partie du logiciel:

• certaines parties non essentielles peuvent être validées une fois par jour
• certaines parties doivent être validées à chaque check-in.

Mais dans ces 2 cas, si il y a un problème, c’est trop tard. Le mal est déjà fait: le code qui génère l’erreur est déjà dans le contrôleur de source sur la branche correspondante. Pour corriger l’erreur, il faut refaire un check-in avec la correction, relancer et relancer la build. Dans certains cas, il n’est pas acceptable de polluer le contrôleur de source avec ce genre de code. Il peut y avoir plusieurs raison à cela:

• Première raison: le code est utilisé est mise à jour très régulièrement pas plusieurs développeurs, et donc si la build échoue ils peuvent potentiellement récupérer du code mauvais
• Le code est critique: algorithme complexe ou un driver par exemple, et toute erreur et donc sa correction peuvent apporter des effets de bords indésirables

Dans ce cas, il faut changer de stratégie: compiler/valider le code dans la build avant le check-in et pas après. C’est ce qu’on appelle le “gated check-in”. Si la build réussie, le code est archivé  par la build sur le compte du développeur.

Comment ca marche: très simple cela se configure sur la build-elle même au moment de sa planification:

Ensuite, au moment du check-in voilà ce qu’il se passe:

On voit bien le nom du shelve (très important pour la suite) et 2 options:

• On peut décider ou nom de garder les fichiers en édition: et oui, comme le check-in n’est pas fait “réellement”, l’état des fichiers ne change pas. On peut aussi avoir l’option d’annuler les changements localement pour revenir dans l’état initial du changeset. Cette dernière option est pratique pour toujours avoir un workspace propre pour plusieurs tâches consécutives à faire.
• Si on a les droits suffisants, on peut aussi courcircuiter le “gated check-in”: les admin ont toujours le dernier mot!

Lançons la build:

Cela ressemble quasiment à une build normale: et à la fin notre code est bien archivé avec le compte du développeur. Comme je le disais plus tôt, le code est archivé que lorsque la build reussie, il suffit maintenant de faire un “get latest” pour se resynchroniser avec le code du serveur ou laisser TFS nous aider:

Faisons maintenant un test avec check-in qui plante:

TFS nous offre directement la possibilité de récupérer le changeset associé à la build pour reposter une correction via “Unshelve changes”. Rien n’empêche un tiers d’effectuer la correction d’un code d’un autre développeur.

Que se passe-t-il maintenant si 2 développeurs modifient en même le même bout de code: ce n’est pas le rôle de TFS de faire des merges:

Code n°1:

Code n°2:

On va ensuite faire un check-in pour chaque fichier. On a donc un shelve pour chacun et le deuxième au moment du check-in ne sera pas basé sur la dernière version du code (puisque cela sera celle du code n°1) .

Les 2 builds s’enchainent:

Et comme on s’y attendait, la première réussie, pas la seconde:

Regardons la deuxième build:

L’erreur correspond à ce qu’il s’attendait à avoir: un problème au moment du merge. La correction est simple: récupèrer le code via la build,  faire un getlatest, resoudre le merge et re-check-in. Et là on croise les doigts de ne s’être pas fait passer devant par un autre collèque sur le même code!

Plus généralement, un getlatest est indispensable pour être sur d’avoir du code qui va s’archiver correctement.

Un seul bémol avec cette technique: cela fait beaucoup de build – autant que si on en lançait après chaque check-in. Mais TFS 2010 est assez configurable pour que vous puissiez avoir assez d’agents de build pour ne pas être débordé et attendre trop longtemps pour valider votre code.

@+

J’ai installé TFS 2010 et après? Contrôle d’accès: c’est pas la fête au village!

Structurellement, TFS est un application 3-tiers : le client (le Team Explorer) la souche de service (qui est à l’adresse de notre serveur) et les bases de données. Nous les développeurs, notre vision s’arrète à la couche de service, c’est à ce niveau que la sécurité est gérée. Je ne compte pas ici faire un tour exhaustif des droits et comptes de sécurité de TFS, mais un tour d’horizon de ce qui est possible de faire avec.

Sécurité au niveau du serveur et des collections de projets

la collection de projet est une segmentation du serveur en entités indépendantes (voir mon billet sur les  Collections de projets). Vous pouvez donc avoir plusieurs équipes distinctes sur le même serveur. Un bon exemple de mutualisation de ressource est la migration de Codeplex sur TFS 2010 .

Concernant les droits du coté du serveur, cela se passe sur la console d’administrateur de TFS :

“Group membership” permet entre autre de donner les droits administrateurs au serveur. Mais être administrateur de TFS est différent de pouvoir administrer TFS via sa console d’admin et  TFS est un ensemble de service:

• des sites sharepoints
• un serveur de rapport SQL Server
• un cube
• ….

Pour pouvoir administrer tout cela, il faut pour chaque compte avoir les bons droits. C’est le role de la liste de utilisateurs de la console d’admin de gérer cela. Lorsque j’ajoute un utilisateur (Bob) à cette liste, la liste des opérations suivantes est réalisée:

Les opérations sont bien sur annulées lorsque l’on retire l’utilisateur de la liste.

SI l’on veut maintenant gérer la sécurité au niveau de la collection de projet, c’est aussi possible dans la console d’administration:

Généralement, à ce niveau, la tâche la plus courante est de définir les administrateurs de la collection de projets. Et si l’on veut définir maintenant plus finement les droits, il va falloir sortir de la console d’administration et d’aller dans le Team Explorer, et là ce n’est plus le rôle de d’administrateur de TFS, mais de celui de la collection.

Contrôle d’accès à la collection de projets et au projet

Nous revoilà dans le Team Explorer. Pas besoin d’avoir accès à la console du serveur pour les prochaines manipulations. Au niveau de la collection, généralement, on ajoute d’autres administrateurs:

Théoriquement on devrait aussi définir les utilisateurs de la collection, mais ce n’est pas la peine.TFS ajoute automatiquement les groupes d’utilisateurs de chaque projet de la collection:

Il suffit donc d’ajouter un utilisateur dans un projet pour qu’il soit autorisé dans la collection.Dans un projet, on ajoute généralement  les utilisateurs dans 3 groupes importants: les administateurs, les contributeurs et les lecteurs. Les administrateurs du projet permettent de modifier les artefacts du projet, les 2 autres groupes sont accès clairs. Coté confidentialité, les workitems d’un projet ne sont visibles par les utilisateurs que si possède les droits de les voir au niveau du projet. Cela est aussi valable pour les autres artefacts comme le contrôleur de source et les builds. Si un utilisateur essaye de voir une information dont il n’a pas accès, il reçoit une erreur comme si cette artefact n’existait pas (Voir http://en.wikipedia.org/wiki/Information_leakage).

Contrôle d’accès au niveau du source

Il  y a parfois des cas ou il faut descendre encore plus bas dans la sécurité: comme les droits par élément du code source. Par exemple: la branche de Fix est uniquement modifiable par l’équipe de support et la branche de release n’est qu’en lecture seule (voir le billet  Organisation des sources). Dans ce cas il suffit d’aller dans le Source Control Explorer et d’aller dans les propriétés du dossier que l’on veut gérer:

Le droit que l’on modifie le plus souvent est le droit de “Check-in”.On touche au droit de “Read” lorsqu’on veut garantir la confidentialité d’une partie du code. Remarque importante: lorsque l’on branche du source, on récupère aussi les droits de la branche parente. C’est une chose tout à fait logique mais on peut se faire surprendre.

Quelques astuces

La chose la plus importante lorsque l’on commence à modifier la sécurité est d’éviter les cas particuliers: il faut toujours essayer de passer par des groupes d’utilisateurs. Si possible définir les droits pour des groupes AD, comme cela tout est fait en dehors de TFS, sinon des groupes TFS et là il faut ajouter manuellement (et supprimer aussi manuellement) les utilisateurs.

Dans TFS, pour chaque droit, il y a une case “Allow” et une case "Deny”. Il faut éviter le plus souvent de cocher la case “Deny”: si un utilisateur fait parti de 2 groupes, dont un qui est en “Allow” et l’autre en "Deny”. Il sera en “Deny” sur ce droit. Surtout que si aucune des 2 cases n’est cochée, il n’y pas accès à la ressource.

Et pour terminer, Team Foundation Sidekicks est un très bon outil pour éditer les droits et régler les problèmes d’accès.

@+

J’ai installé TFS 2010, et après ? Mise en prod: it’s the final countdown!

Un moment critique de la vie d’un projet est le moment de la livraison. Ce moment est d’autant plus critique (certains diraient douloureux)  que le nombre de livraison est faible. Généralement on livre au minimum une fois .

Comment je livre, et qu’est ce que je livre?

Il y a la recette de grand-mère, et la recette du chef.

Dans la recette de grand-mère, nous avons un développeur (pas toujours le même). Quelque soit sa bonne volonté, un développeur ne livrera jamais 2 fois le logiciel de la même façon, et surtout la compilation dépendra de sa machine et il y a de bonnes chances qu’il oublie quelque chose.

Dans la recette du chef, nous avons une build. La build c’est un peu le super développeur en ce qui concerne la compilation, il fera toujours tout de la même façon, autant de fois que l’on veut et à n’importe quelle heure de la journée. Ce qui veut dire que l’on a pas besoin d’attendre le dernière moment pour préparer l’installeur.

Cela veut aussi dire que l’on le lance pas forcément la build lorsque l’on a terminé, mais que c’est plutôt la build qui va nous dire si nous avons terminés. La build:

• compile le logiciel et fournit l’installeur,
• exécute les tests,
• génère des métriques de qualité de code (couverture, analyse statique) qui nous donne un indice sur le code généré,
• permet de générer des informations sur le code churn: si il y a beaucoup de code churn, il se peut qu’il y ait une plus grosse probabilité de bug,
• génère des symboles de debug et les associe à la version du code,
• associe des workitems pour identifier les dernières modifications.

Tout cela sera la base de notre livraison.

Est-ce que cela fait ce que cela doit faire et est-ce que je n’ai rien oublié?

Pour le premier point, c’est simple: via les rapports de TFS et les workitems… si tout est bien renseigné! Lorsque l’on a un doute, il va falloir analyser le source.

Prenons un exemple. Une application avec une main, et 1 release: R1. Un fix est fait dans la branche R1 (changeset 14) et est mergé dans la main (changeset 15). Une branche de release R2 a été créé. La question est la suivante: est-ce que bug est corrigé dans la R2? Dans le langage TFS, la question devient: est-ce que le changeset du bug a été fusionné dans la branche R2.

Première étape: regardé ce que devient le code du changeset 14 (celui de notre correction). Dans VS 2010, nous avons la possibilité d’avoir une vue historique de l’évolution d’un changeset concernant les merges:

Le changeset 14 a été mergé dans le changeset 15 dans la main. Nous savons donc que la correction a été reporté dans la main. Regardons maintenant le changeset 15:

Bonne nouvelle, il a été fussionné dans R2 dans le changetset 16! La correction est donc bien dans la nouvelle branche de release.

C’est en prod et maintenant?

Maintenant que tout est en prod. Que peux faire TFS pour nous, en plus des workitems de bug? Comme je n’ai écrit plus haut, la build génère les symboles de debug et les liens avec le source. Cela va être extrêmement pratique car il n’est pas question de fournir les symboles de débug avec l’installation du programme! Cela veut aussi dire que lors qu’un correctif doit être livré, il devra aussi être compilé avec la build pour avoir ces informations: il faut donc une build pour chaque branche de livraison.

Si deux releases nécessitent des environnements différents, ne prenez pas de risque: utiliser 2 machines de builds. Une machine de build n’a pas forcément besoin d’être puissante: un PC inutilisé fera l’affaire du moment que son environnement est contrôlé.

Un dernier conseil pour finir: bien suivre le branching guide pour ne pas avoir de problèmes!

@+

J’ai installé TFS 2010, et après? Aujourd’hui je code ce qu’il me plaît…mais avec des work items.

L’avantage de TFS par rapport à ce simple contrôleurs de source, c’est sa possibilité d’associer des work items à un check-in. Ok, mais quel est l’avantage par rapport à un commentaire? C’est simple un commentaire est un élément du changeset (le check-in avec ses fichiers) , et le workitem y est juste lié. Il sera donc lié à chaque changeset et sur le work item on pourra y voir cette liste:

Autre gros avantage: lors de la build, on va pouvoir avoir la liste des workitems associés aux changeset:

Il faut y voir ici un élément essentiel dans la traçabilité des modifications du logiciel:

• le commentaire du changeset indique ce que l’on a fait: notre action
• le workitem indique pourquoi on l’a fait: notre intention

Généralement, on a toujours une bonne raison de modifier le logiciel. Par example:

• une tâche précise de travail (reliée à un élément du business)
• un bug
• une tâche plus technique sans forcément de valeur ajoutée facilement identifiable: tâches d’audit, refactoring, évolution de l’usine logicielle…

Dans les 2 première cas, c’est toujours assez facile d’avoir un work item. Dans le dernier cas, c’est plus difficile, car les tâches n’ont pas un but bien précis. Mais cela n’est pas grave, un workitem peut être généraliste, mais dans ce cas, le commentaire du changeset se doit d’être plus précis.

Si l’on souhaite créer des workitems rapidement, il y a une façon accélérée de le faire: c’est de passer via les powertools de TFS. Il suffit de créer des templates:

Comment faire pour que l’équipe “n’oublie pas” de rentrer soit le work item ou même le work item? Là aussi il y a dans TFS une solution: les “check-in” policies ou polique d’archivage. Elles sont accessibles via les propriétés du projet:

Mais attention, elles sont débrayables par l’utilisateur. Cela peut arriver lorsque l’on doit corriger quelque chose en urgence, et que le work item n’existe pas encore Cela doit rester exceptionnel, car dans ce cas on perd la traçabilité de la modification du logiciel. Pour détecter ce genre de chose TFS a aussi une solution: les alertes:

Je ne rentrerai pas dans les détails, mais via l’alert explorer on peut ajouter une alerte que l’on va envoyer à toute l’équipe lorsqu’un work item est créé en débrayant une polique de check-in. Je parlerai des alertes avec plus de détail dans un autre billet.

Une dernière chose: il est toujours possible de changer le commentaire et aussi d’y associé un nouveau workitem même pour un changeset archivé. Pour le commentaire, il faut passer par l’historique dans le “source control explorer” et dans le deuxième il faut ajouter un lien dans le workitem que l’on veut associer. Contourner ces politiques de check-in n’est donc pas une fatalité, mais il faut ensuite s’assurer que les ajustements soient fait.

@+

J’ai installé TFS 2010, et après ? Horreur malheur! ma build a planté!

Ce qui devait arriver arriva. La build a échouée à la compilation. Que fait-on maintenant? L’erreur serait d’ouvrir la solution qui est compilé par la build sans regarder d’où vient le problème. Erreur car:

• La version que l’on a sur son poste marche peut-être: c’est surement pas la même version que la build
• Il y plus rapide pour trouver l’erreur que de récupérer le code du label de la build (même si au final il faudra y venir)

Une build qui marche, cela ressemble à cela:

La partie la plus intéressente lorsque l’on suit une build est la liste des changesets associés. Pour chaque build, TFS pose un label sur le code. Ce label sert à récupérer le code si tout va bien pour définir une version à livrer et tirer une branche, et si tout va mal pour corriger la build. TFS garde pour chaque définition de  build le label de la dernière build réussie. A partir de ce label, on en déduit les changesets et donc on sait ce qui a changé depuis la dernière build réussie:

Regardons maintenant la build qui a échouée:

Ici c’est assez clair, mais souvent il faut creuser un peu pour trouver le problème. Et généralement on commence à creuser en regardant les changesets associés, car si la build a planté et que celle d’avant marchait, c’est forcément là que l’on va trouver le problème, et surtout si la correction est complexe, la personne qui va corriger tout cela (et oui corriger la build c’est l’affaire de tous!)

Lorsque l’on clique sur le nom du changeset, on arrive sur son détail:

Ensuite il suffit de comparer avec la version précédente:

Et on tombe sur l’erreur:

Cet exemple est un peu caricatural sur plusieurs points:

• Il n’y a généralement pas qu’une erreur, mais un généralement un grand nombre d’erreurs “leurres” qui découlent d’une ou plusieurs erreurs: un using de namespace manques et dont le code compile plus mais l’erreur c’est que le “using” a disparu et cela aucun compilateur vous le dira.
• Il y a souvent beaucoup de changesets: il faut alors les parcourir, mais si les développeurs ont l’habitude de mettre des commentaires sur les changesets et cela aide beaucoup.

Dans tous les cas, la build est le meilleur allié pour voir comment évolue le logiciel et identifier les problèmes. La build est capable de plein d’autres choses, mais ça c’est pour un autre billet.

@+

Fissum 1.0 pour VS 2010

Ca faisait un bon moment que je n’avais pas mis à jour Fissum. J’ai profité des derniers mois pour réécrire entièrement l’application en WPF et ciblé uniquement VS 2010:

J’ai aussi directement intégré le workflow de mon autre projet Codeplex qui s’affiche si ce composant n’est pas dans le process template.

La version se trouve ici: http://fissum.codeplex.com/releases/view/59661

Bon téléchargement!

@+

J’ai installé TFS 2010, et après ? Une build ça ne sert pas qu’à compiler, mais finalement c’est déjà pas mal!

Qui n’a jamais entendu une des choses suivantes:

• Je ne comprends pas ca marche sur ma machine
• Ca va plus vite de déployer directement depuis mon poste
• Fais-moi confiance, j’ai compilé avec les bonnes versions des bibliothèques tierces.
• Je sais plus quelle version j’ai compilé, j’ai pas mis de label.

Et qui n’a jamais eu ces résultats:

• Ca ne compile QUE sur son poste
• Il manque des fichiers lors du déploiement, mais il ne pouvait pas savoir dit-il.
• Il ne savais pas qu’on avait changé de version de composants
• On ne sait pas quelle version est en prod

En bref, dès que l’on laisse la responsabilité de la compilation du logiciel sur un poste de développeur, cela devient vite problématique. Ce n’est pas seulement du à un problème entre la chaise et le clavier, mais à ce qui fait la caractéristique même du poste de travail du développeur. Le poste du développeur n’est pas figé, il évolue  dans le temps: nouveaux outils installés, nouveaux programmes à compiler…

C’est pour cela qu’un poste de build dédié est important:

• il a toujours la même configuration
• il est contient les bibliothèques nécessaires à la compilation dans leur bonne version
• Personne ne travaille dessus
• Son installation est documentée lorsqu'elle est complexe pour être reproductible. Il y a au moins la liste des outils nécessaires à la compilation avec le numéro de version correspondant.

La build a toujours raison!

Cette machine est donc capable de compiler 2 versions du logiciel dans le même environnement. Ce qui veut dire que si la première version compile, mais pas la seconde, c’est du généralement à un problème coté développeur. Et à choisir entre croire la machine de build et le développeur, je crois généralement la machine de build. Pour quelles raisons cela compile sur le poste du développeur alors que cela ne devrait pas:

• Il n’a pas la bonne version du code source (un petit oubli de GetLatest…)
• Il n’a pas la bonne version des bibliothèques, ou il utilise une mauvaise version du framework
• …

Le plus long à faire pour la création d’une machine de build est de trouver la machine, car une fois qu’elle est disponible et dédiée à l’équipe, l’installation est simple. Généralement l’accès à la machine de build est restreint car personne n’a théoriquement  le droit de s’y connecter, à part pour de la maintenance ou des évolutions d’outils. Dans certains cas, où la résolution du problème n’est tout simplement pas possible sur les postes des développeurs car l’erreur n’est pas reproductible, il est tout à fait possible de corriger le bug directement sur la machine de build, mais cette option est à éviter.

Dans tout cela si je devais garder qu’un une image, je pense que cela serait celle-ci:

@+

J’ai installé TFS 2010, et après ? Oui on peut avoir plusieurs workspaces et c’est une bonne idée

D’expérience, la notion de workspace est l’une des notions les moins connues de TFS et pourtant c’est une des notions les plus importantes. Un workspace est un mapping entre des chemins sur l’ordinateur courant et des chemins sur un serveur TFS. Si l’on s’arrête à cela, il n’y a pas forcément un avantage d’avoir plusieurs workspaces. Là où cela devient intéressant est lorsque l’on apprend qu’une modification sur un fichier est liée au workspace utilisé, et que lorsqu’on archive un fichier ou un ensemble de fichiers, on travaille sur un seul workspace à la fois.

Prenons 2 exemples:  Alice et Bob travailles sur le même projet.

Alice a un seul workspace, le workspace par défaut qu’a créé Visual Studio lorsqu’elle s’est connectée au serveur la première fois. On reconnait ces workspaces car ils ont le nom de la machine. Elle travaille à la fois sur une version en développement du logiciel et sur un correctif. Dans le même workspace elle va donc avoir simultanément des éléments à archiver pour la version en développement et des éléments du correctif. Alice va devoir trier les fichiers et vérifier qu’elle archive bien ceux de la bonne version du logiciel, et surtout qu’elle n’en oublie pas!

Bob a plusieurs workspaces, un pour la version en développement “NOMMACHINE”_DEV et sur un correctif “NOMMACHINE_FIX78979”. Il sépare sont code en 2 mappings un pour chaque workspace. Il est donc sûr lorsqu’il archive tout un workspace de n’oublier aucun fichier et de ne pas avoir pris dans l’archivage un fichier d’un correctif. Créer un workspace prend 2 minutes. et le nom est bien visible dans le “Source Control Explorer” et la fenêtre des “Pendings Changes”:

Comment empécher ce comportement? C’est assez simple: avec un outil comme Team Foundation Sidekicks, on peut lister les workspaces des utilisateurs du serveur et leur demander de les supprimer en leur expliquant l’utilité d’en créer un par but.

Vous avez aussi la date de la dernière utilisation, ce qui vous permet de faire le ménage!

@+