Ajouter des champs pour prendre en charge l'intégration avec un test, une build et un contrôle de version

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, Microsoft Test Manager 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, et Team Foundation Build peut générer des éléments de travail en cas de échec d'une build.Elle peut également ajouter les informations de build aux éléments de travail qui ont été résolus dans une build particulière.Pour que ce code fonctionne, Team Foundation Build requiert que les deux champs suivants sont ajoutés à la définition du type d'élément de travail : Trouvé dans et Build d'intégration.

Dans les modèles de processus par défaut qu' Team Foundation Server fournit, Trouvé dans et les champs Intégré dans la build apparaissent dans les définitions de type des bogues.Ces champs sont des bogues aux builds dans lesquelles ils ont été trouvés ou résolus.Vous pouvez utiliser l'extrait de code suivant pour ajouter ces champs à une définition de type d'élément de travail.

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

Lorsque le champ Trouvé dans est présent dans la définition du type d'élément de travail, Team Foundation Build crée un élément de travail lorsque la build échoue, et définit le champ Trouvé dans au numéro de la build n'a qu'échoué.Si le champ Trouvé dans est manquant, Team Foundation Build ne crée pas d'élément de travail pour la génération, mais tout le reste fonctionne comme prévu.

Lorsque le champ Build d'intégration est présent dans la définition du type d'élément de travail, Team Foundation Build identifie les éléments de travail qui ont été résolus avec chaque génération puis met à jour les éléments de travail pour définir le numéro de build dans lequel ils ont été résolus dans le domaine Build d'intégration .Si le champ Build d'intégration 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.

Pour plus d'informations, consultez Référence de champ Générer et Tester.

Champs qui s'intègrent au gestionnaire de tests Microsoft

Avec Gestionnaire de tests, vous pouvez automatiser la création d'un bogue ou tout autre type d'élément de travail en cas de échec d'un test.Pour plus d'informations, consultez Envoi de bogues dans Microsoft Test Manager.

Lorsqu'un élément de travail a été créé de cette manière, les informations sur le système et les étapes pour reproduire le bogue sont capturées dans les champs Informations système et de Étapes de reproduction .

Vous pouvez ajouter ces champs aux types d'éléments de travail que vous créez pour le suivi des erreurs à l'aide de l'extrait de code suivant.

<FIELD name="System Info" refname="Microsoft.VSTS.TCM.SystemInfo" type="HTML" />
<FIELD name="Repro Steps" refname="Microsoft.VSTS.TCM.ReproSteps" type="HTML" />

Pour plus d'informations sur les autres champs utilisés par Gestionnaire de tests, consultez Référence de champ Générer et Tester.

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.

[!REMARQUE]

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

Concepts

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

Autres ressources

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

Historique des modifications