Champs prenant 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 de façon à ce 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 au contrôle de version 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 avec Team Foundation Build, et Team Foundation Build peut générer des éléments de travail en cas d'échec d'une build. Il peut également ajouter des informations de build aux éléments de travail qui ont été résolus dans une build particulière. Pour cela, Team Foundation Build exige l'ajout des deux champs suivants à la définition du type d'élément de travail : Found In (Trouvé dans) et Integration Build (Build d'intégration).

Dans les modèles de processus par défaut fournis par Team Foundation Server, les champs Trouvé dans et Build d'intégration apparaissent dans les définitions de type des bogues. Ces champs associent les 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>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
</FIELD>
<FIELD name="Integration Build" refname="Microsoft.VSTS.Build.IntegrationBuild" type="String" reportable="dimension">
    <HELPTEXT>Product build number this bug was fixed in</HELPTEXT>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
</FIELD>

Si le champ Trouvé dans est présent dans la définition d'un type d'élément de travail, Team Foundation Build crée un élément de travail en cas d'échec d'une build et affecte le numéro de build de celle-ci au champ Trouvé dans. Si le champ Trouvé dans est manquant, Team Foundation Build ne crée pas d'élément de travail lors de l'échec d'une build, mais tout le reste fonctionne comme prévu.

Quand 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 résolus dans chaque build, puis met à jour ces éléments de travail en affectant le numéro de build dans lequel ils ont été résolus au champ 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.

Association d'ensembles de modifications et d'éléments de travail à des builds

Une build standard basée sur le modèle de build par défaut est associée à des ensembles de modifications et à des éléments de travail. Pour cela, elle récupère tout d'abord l'étiquette de la build précédemment réussie pour la définition de build de la build donnée, puis détermine les ensembles de modifications inclus dans la build actuelle qui ne figuraient pas dans la version précédente. Si des éléments de travail sont associés à une partie ou à la totalité des ensembles de modifications, ils sont alors associés à la build. Cette opération est effectuée dans le cadre de l'activité AssociateChangesetsAndWorkItems.

Remplissage automatique des builds et de la liste globale

La première fois que vous mettez une build en file d'attente pour un projet d'équipe à l'aide de Team Foundation Build, TFS ajoute automatiquement une liste globale intitulée « Build - <nom du projet d'équipe> ». Chaque fois qu'une build est exécutée, un élément LISTITEM est ajouté à cette liste globale avec le nom de la build.

Si vous ajoutez un élément GLOBALLIST à la définition de FIELD, les utilisateurs se voient proposer un menu déroulant dans lequel ils peuvent sélectionner une build. Par exemple :

<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>
        <SUGGESTEDVALUES>
          <LISTITEM value="&lt;None&gt;" />
        </SUGGESTEDVALUES>
        <SUGGESTEDVALUES expanditems="true" filteritems="excludegroups">
          <GLOBALLIST name="Builds - TeamProjectName" />
        </SUGGESTEDVALUES>
</FIELD>

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

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

Si un élément de travail est créé de cette manière, les informations relatives au système et les étapes à suivre pour reproduire le bogue sont capturées dans les champs Informations système (System Info) et Étapes de reproduction (Repro Steps).

Vous pouvez ajouter ces champs aux types d'éléments de travail que vous créez pour effectuer 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 champs supplémentaires utilisés par le Gestionnaire de tests, voir Référence des champs d'intégration de build et de tests.

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 quand vous archivez du code. Si vous travaillez sur un élément de travail particulier pendant que vous modifiez du code, vous pouvez définir cette association à partir de la fenêtre d'archivage du contrôle de code source une fois vos modifications terminées.

Pour que le contrôle de version Team Foundation puisse résoudre un élément de travail, ce dernier doit contenir une action particulière. Le système de contrôle de code source interroge alors 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, interroge les états source et 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

Quand vous utilisez l'action Checkin, vous devez définir les états « from » et « to » pour refléter la transition d'état de votre choix.

Pour plus d'informations sur Actions, voir Automatiser les assignations des champs par état, transition ou raison.

Exemple de l'action Checkin

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

Q et R

Q : Quels sont les autres champs associés aux builds et au Gestionnaire de tests ?

R : Voir Référence des champs d'intégration de build et de tests pour obtenir la liste des champs supplémentaires.

Voir aussi

Tâches

Quel développement a-été effectué depuis une build antérieure ?

Autres ressources

Modifier ou ajouter un champ pour prendre en charge les requêtes, les rapports et le flux de travail