Ajout de champs d'intégration dans des types d'éléments de travail
Mise à jour : novembre 2007
Le système du suivi des éléments de travail Team Foundation s'intègre avec d'autres composants de Team Foundation Server et de Visual Studio Team System. Pour optimiser l'intégration entre composants, vous utilisez certains champs et actions dans les types d'éléments de travail. Cette rubrique décrit comment vous utilisez ces champs et actions obligatoires dans les sections suivantes :
Intégration avec Team Build
Intégration avec les outils de test Visual Studio
Intégration du contrôle de code source Team Foundation
Intégration avec 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 lorsqu'une génération échoue. Il peut également ajouter des informations de génération aux éléments de travail qui ont été résolus dans une génération particulière. Pour ce faire, Team Foundation Build requiert les deux champs suivants : Found In et Integration Build.
Ajout du champ Trouvé dans
Team Foundation Build crée un élément de travail lorsqu'une génération échoue et attribue le champ Found In au numéro de build de la génération qui vient d'échouer. 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 |
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 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>
Intégration avec les 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. La capacité à créer de nouveaux éléments de travail lorsqu'un test échoue fait partie des fonctionnalités disponibles 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 pour lequel vous souhaitez créer un bogue, pointez sur Créer un élément de travail, puis cliquez sur le type d'élément de travail que vous souhaitez créer, par exemple Bogue. Pour plus d'informations, consultez Comment : créer un élément de travail à partir d'un résultat de test.
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. Visual Studio Test Edition définit ces trois champs avec des informations spécifiques relatives au test qui a é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 |
Chaîne |
Exemple des 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>
Intégration du contrôle de code source Team Foundation
L'une des fonctionnalités du contrôle de version Team Foundation est que vous pouvez associer ou résoudre des éléments de travail tout en archivant le code. Vous avez probablement 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 tout en archivant le code.
.gif "Remarque") 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 Association d'une transition d'état à une action et Détails des actions de transition.
Exemple de l'action Archivage
<TRANSITION from="Active" to="Resolved">
....
<ACTIONS>
<ACTION value="Microsoft.VSTS.Actions.Checkin"/>
</ACTIONS>
....
</TRANSITION>
Voir aussi
Tâches
Comment : créer un élément de travail à partir d'un résultat de test
Concepts
Association d'une transition d'état à une action
Détails des actions de transition