2009-05-20 10 views
2

Nous venons de commencer avec Team Foundation Server 2008/Visual Studio Team System et nous sommes heureux de trouver comment exporter et modifier des éléments de travail selon nos besoins. Cependant, cette dernière chose qui rendrait la parfaite configuration pour nous est révélée un peu difficile:Appliquer le lien dans l'élément de travail de bug Team Foundation Server pour les doublons

Nous avons exporté le Bug travail type d'élément et ont apporté des modifications à voir apparaître différemment à différents groupes d'utilisateurs. Nous constatons cependant un problème potentiel chez les non-développeurs signalant des bogues qui se révèlent être des doublons. Nous souhaitons que les utilisateurs qui clôturent un ticket avec raison résolue: duplicate créent également un lien vers le bug qui est perçu comme le premier rapport de bug.

J'ai regardé System.RelatedLinkCount et mettre la règle

<FIELD type="Integer" name="RelatedLinkCount" refname="System.RelatedLinkCount"> 
    <WHEN field="Microsoft.VSTS.Common.ResolvedReason" value="duplicate"> 
     <PROHIBITEDVALUES> 
     <LISTITEM value="0" /> 
     </PROHIBITEDVALUES> 
    </WHEN> 
    </FIELD> 

Cependant, lorsque je tente de mettre quelque chose dans ce cadre, l'importateur me dit que System.RelatedLinkCount n'accepte pas la règle, pas importe ce que je mets, mais la règle ci-dessus montre ce que j'essaie de faire (même si la règle la plus préférable vérifie aussi que le bug auquel je suis lié n'est pas un doublon, bien que ce soit trop: P)

Est-ce que quelqu'un d'autre a essayé d'appliquer des règles comme celle-ci dans les éléments de travail? Y a-t-il une autre approche pour résoudre le même problème? Je suis reconnaissant pour toute réflexion à ce sujet.

Répondre

0

Faire exactement ce que vous voulez est assez difficile dans les versions actuelles de TFS. (Le lien avancé de 2010 le rend plus facile.) Je crois que vous devriez écrire votre propre type de lien au minimum, et peut-être aussi un contrôle de champ personnalisé. Ces interfaces ne sont pas très bien documentées sur MSDN, bien qu'il existe des exemples sur des blogs tiers.

La meilleure solution de compromis IMO est de créer un nouveau champ entier appelé «ID de bogue en double». Lorsqu'un bogue passe à l'état Résolu et que le champ Résolution est "dupliqué", ce champ devient obligatoire. Toutes les autres fois, il est en lecture seule (et vide par défaut). De cette façon, toutes les informations que vous désirez sont capturées. Les inconvénients sont:

  • le "lien" n'est pas bidirectionnel; aucun moyen de voir le bug original un plus tard a été dupé contre
  • naviguer vers le bug d'origine de la duper nécessite CTRL + G au lieu de doubleclicking

Je pense que ce sont mineures pour une solution rapide qui répond à 90% des besoins restants.

1

Je ne suis pas sûr d'empêcher cela directement sur la résolution du bogue en double. Même avec l'idée sur laquelle vous travaillez, il n'y a pas de validation du lien à un bug réel. Ce que vous pourriez essayer à la place est d'écrire un rapport qui vérifie que tout bogue résolu en double a un lien associé qui va à un autre bogue. Demandez aux membres de l'équipe responsable d'examiner ce rapport une fois par semaine environ. Un peu de "blâme et de honte" de bonne nature va un long chemin à garder un projet propre. ;)

0

Vous pouvez accomplir cela en créant un champ de chaîne "buddy" qui définit sa valeur en fonction du Lien Relatif, puis applique des règles sur le champ de contact selon la raison résolue.

Questions connexes