Michel Perfetti [Miiitch]

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.

@+