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

Article
08/10/2011

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

Partager via