Partager via


Ajout de champs d'intégration dans des types d'éléments de travail

Vous pouvez personnaliser des types d'éléments de travail afin qu'ils contiennent des informations générées par des processus automatisés en ajoutant des champs qui s'intègrent à Team Foundation Build, Gestionnaire de tests Microsoft et contrôle de version Team Foundation. 

Dans cette rubrique

  • Champs qui s'intègrent à Team Build

  • Champs qui s'intègrent aux outils de test Visual Studio

  • Champs qui s'intègrent au contrôle de code source Team Foundation

Champs qui s'intègrent à Team Foundation Build

Team Foundation Build est le système de génération automatisé de Team Foundation Server. Vous pouvez configurer votre processus de génération à l'aide de Team Foundation Build. Team Foundation Build peut générer des éléments de travail en cas d'échec d'une build, et peut également ajouter des informations de build aux éléments de travail résolus dans une build particulière. Pour ce faire, Team Foundation Build nécessite les deux champs suivants : Found In et Integration Build.

Ajout du champ Trouvé dans

Team Foundation Build crée un élément de travail en cas d'échec d'une build et attribue au champ Found In le numéro de la build ayant échoué. Le champ Found In doit être présent dans le type d'élément de travail à créer par Team Foundation Build lorsqu'une génération échoue. Si le champ Found In est manquant, Team Foundation Build ne crée pas d'élément de travail pour la génération qui a échoué, mais tout le reste fonctionne comme prévu.

Le tableau suivant récapitule les noms et valeurs des attributs de champ Found In.

Nom d'attribut

Valeur d'attribut

RefName

Microsoft.VSTS.Build.FoundIn

Nom

Peut avoir n'importe quelle valeur car le fonctionnement des intégrations est basé sur les noms de références de champs, et non pas sur les noms de champs.

Type

Chaîne

Exemple du champ Trouvé dans

<FIELD name="Found In" refname="Microsoft.VSTS.Build.FoundIn" type="String" reportable="dimension">
    <HELPTEXT>Product build number (revision) in which this item was found</HELPTEXT>
</FIELD>

Ajout du champ Build d'intégration

Team Foundation Build identifie les éléments de travail qui ont été résolus avec chaque génération, puis les met à jour pour définir le numéro de build dans lequel ils ont été résolus. Il définit le numéro de build dans le champ Integration Build Si le champ Integration Build est manquant, Team Foundation Build ne stocke pas le numéro de build dans les éléments de travail mais tout le reste fonctionne comme prévu.

Le tableau suivant récapitule les noms et valeurs des attributs de champ Integration Build.

Nom d'attribut

Valeur d'attribut

RefName

Microsoft.VSTS.Build.IntegrationBuild

Name

Peut avoir n'importe quelle valeur car le fonctionnement des intégrations est basé sur les noms de références de champs, et non pas sur les noms de champs.

Type

Chaîne

Exemple du champ Build d'intégration

<FIELD name="Integration Build" refname="Microsoft.VSTS.Build.IntegrationBuild" type="String" reportable="dimension">
    <HELPTEXT>Product build number this bug was fixed in</HELPTEXT>
</FIELD>

Champs qui s'intègrent aux outils de test Visual Studio

Certaines versions de Visual Studio incluent des outils de test qui sont intégrés dans l'environnement de développement. Il est possible de créer des éléments de travail en cas d'échec d'un test dans les outils de test. Pour ce faire, dans la fenêtre Résultats des tests, cliquez avec le bouton droit sur le résultat de test pour lequel vous voulez créer un bogue, pointez sur Créer un élément de travail, puis cliquez sur le type d'élément de travail à créer, par exemple Bogue. Pour plus d'informations, consultez How to: Create a Work Item from a Test Result.

Lorsqu'un élément de travail a été créé de cette manière, trois champs peuvent être remplis automatiquement pour fournir des informations sur l'échec du test. Les trois champs sont TestName, TestId et TestPath. Gestionnaire de tests définit ces trois champs à l'aide d'informations spécifiques sur le test ayant échoué. Si les champs TestName, TestId et TestPath sont absents de l'élément de travail, les champs ne sont pas définis mais tout le reste fonctionne comme prévu.

Le tableau suivant récapitule les noms et les valeurs des attributs de ces trois champs.

Nom d'attribut

Valeur d'attribut

RefName

Microsoft.VSTS.Test.TestName, Microsoft.VSTS.Test.TestId, Microsoft.VSTS.Test.TestPath

Name

Peut avoir n'importe quelle valeur car le fonctionnement des intégrations est basé sur les noms de références de champs, et non pas sur les noms de champs.

Type

String

Exemple de champs TestName, TestId et TestPath

<FIELD name="Test Name" refname="Microsoft.VSTS.Test.TestName" type="String" reportable="detail">
    <HELPTEXT>The name of the test that found this bug</HELPTEXT>
</FIELD>
<FIELD name="Test Id" refname="Microsoft.VSTS.Test.TestId" type="String" reportable="detail">
    <HELPTEXT>The Id of the test that found this bug</HELPTEXT>
</FIELD>
<FIELD name="Test Path" refname="Microsoft.VSTS.Test.TestPath" type="String" reportable="detail">
    <HELPTEXT>The full pathname of the test that found this bug</HELPTEXT>

Champs qui s'intègrent au contrôle de version Team Foundation

L'une des fonctionnalités disponibles dans le contrôle de version Team Foundation vous permet d'associer ou de résoudre des éléments de travail lorsque vous archivez du code. Vous avez peut-être travaillé sur un élément de travail donné lors de la modification d'un code donné, et vous pouvez définir cette association à partir de la fenêtre d'archivage du contrôle de code source lorsque vous avez fini de travailler sur le code.

La capacité du contrôle de version Team Foundation à résoudre un élément de travail requiert que les éléments de travail contiennent une action particulière. Le système de contrôle de code source interroge ensuite le suivi des éléments de travail pour déterminer si l'élément de travail prend en charge cette action et, si tel est le cas, il interroge également la source et les états de destination de la transition. Si l'action est trouvée, le système de contrôle de code source peut effectuer la transition de l'élément de travail en fonction de la transition définie lors de l'archivage du code.

Notes

Lorsque vous utilisez l'action Checkin, vous devez définir les états "de" et "à" pour refléter la transition d'état de votre choix.

Pour plus d'informations sur les actions, consultez Associating a State Transition with an Action et Transition Action Details.

Exemple de l'action Archivage

<TRANSITION from="Active" to="Resolved">
....
    <ACTIONS>
        <ACTION value="Microsoft.VSTS.Actions.Checkin"/>
    </ACTIONS>
....  
</TRANSITION>

Voir aussi

Tâches

How to: Create a Work Item from a Test Result

Concepts

Identification des builds qui ont des résolutions de bogues, de nouvelles fonctionnalités ou des spécifications

Associating a State Transition with an Action

Transition Action Details

Personnalisation des données de suivi de projet, de formulaires, de flux de travail et d'autres objets

Autres ressources

Définition et personnalisation du flux de travail des éléments de travail

Identification de vos besoins en matière de personnalisation des processus et du suivi