Automatiser les assignations des champs par état, transition ou raison
Vous pouvez faire transiter automatiquement des éléments de travail d'un état à un autre en fonction d'un événement qui se produit ailleurs dans Visual Studio Application Lifecycle Management (ALM) ou en dehors de Visual Studio ALM. Par exemple, vous pouvez automatiser la transition d'un bogue d'un état à un autre en fonction d'un événement qui se produit dans un outil de suivi des appels. Le modèle du type d'élément de travail et l'API de suivi des éléments de travail sont étendus pour prendre en charge la transition automatique d'éléments de travail exécutée par d'autres systèmes.
Si vous disposez d'un code qui modifie l'état d'un élément de travail, vous pouvez généraliser ce code en associant votre action à la transition d'état appropriée à l'aide de l'élément ACTION. Vous pouvez transmettre la valeur de votre action à la méthode [WorkItem.GetNextState] pour obtenir l'état de post-action de cet élément de travail. La boîte de dialogue d'archivage du contrôle de version utilise cette méthode pour résoudre des bogues et fermer les tâches associées à l'archivage.
ACTION est un élément enfant facultatif de ACTIONS.
Notes
L'API de suivi des éléments de travail fait partie du Kit de développement logiciel (SDK) Visual Studio ALM, comme décrit dans la page suivante du site web Microsoft : Extension de Team Foundation.
Par exemple, un outil est prédéfini pour faire transiter automatiquement un élément de travail vers l'état « Résolu », après que l'utilisateur a archivé une modification. Toutefois, en tant que fournisseur d'intégration, vous ne savez pas quel état l'auteur du type d'élément de travail a déclaré comme « Résolu ». L'auteur peut signifier Résolu, Fermé, Terminé, Prêt pour le test, Inclure dans la build, etc. L'une des options serait de demander à tous les auteurs de type d'élément de travail d'inclure un état explicite appelé « Résolu ».
Cette solution est trop restrictive. Elle est également inadaptée dans une perspective internationale, car elle ne permet pas la localisation des états. Les intégrateurs système peuvent plutôt déclarer une action, telle que « Archivage » ou « Terminé », qui déclenche une transition automatique des éléments de travail. L'auteur du type d'élément déclare alors cette action sur la transition appropriée.
Dans cette rubrique
Syntaxe de l'élément ACTION
Étapes requises pour la prise en charge de l'automatisation
Association d'une transition d'état à une action
Détails des actions de transition
Vérification des erreurs de transition automatique
Syntaxe de l'élément ACTION
La syntaxe suivante est utilisée pour l'élément ACTION. L'attribut value spécifie le nom de l'action. Il est obligatoire. Vous devez utiliser les mêmes conventions d'affectation de noms pour les actions que pour les noms de référence de champ. Par exemple, le contrôle de version contrôle de version Team Foundation utilise Microsoft.VSTS.Actions.CheckIn pour identifier la transition qui est appropriée pour les éléments de travail associés à l'archivage. Pour plus d'informations, consultez Conventions d'affectation de noms pour les objets de suivi des éléments de travail.
<ACTION value="NameOfAction" />
minOccurs="0"
maxOccurs="unbounded"
Étapes requises pour la prise en charge de l'automatisation
Pour intégrer un outil avec la fonctionnalité Suivi des éléments de travail, cet outil doit effectuer les étapes suivantes :
Déterminer l'état vers lequel l'élément de travail doit transiter lorsque l'action est exécutée.
Attribuer à l'élément de travail l'état « to ».
L'API de suivi des éléments de travail fournit des méthodes permettant d'exécuter ces étapes. L'API de suivi des éléments de travail fait partie du Kit de développement logiciel (SDK) Visual Studio ALM. Pour plus d'informations, consultez la page suivante sur le site Web Microsoft : Kit de développement logiciel (SDK) Team Foundation Server.
Notes
L'action de transaction qui a provoqué une transition d'état spécifique n'est pas enregistrée.Si vous devez effectuer le suivi d'une action qui a provoqué une transition, vous pouvez spécifier un champ d'élément de travail supplémentaire pour ce suivi, ou vous pouvez définir une valeur dans le champ Raison.
Retour au début
Association d'une transition d'état à une action
Vous pouvez utiliser des actions de transition d'état pour automatiser les transitions d'éléments de travail à différents points dans leur flux de travail. Par exemple, un système de contrôle de version Team Foundation Server doit prendre en charge les transitions automatiques d'éléments de travail au moment de l'archivage. Pour ce faire, une action « microsoft.vsts.actions.checkin » a été définie.
Un auteur de type d'élément de travail peut définir un type d'élément de travail « Defect » dont l'état est appelé « Working » et l'utiliser lorsqu'un développeur apporte des modifications. L'auteur du type d'élément de travail peut définir un autre état appelé « Ready To Build » qui signifie que le développeur a déclaré que le code qui a été affecté par la défaillance est prêt pour la génération nocturne.
L'auteur peut automatiquement faire passer l'élément de travail de l'état « Working » à l'état « Ready To Build » au cours d'une opération d'archivage en déclarant les éléments suivants :
<TRANSITION from="Working" to="Ready To Build">
<ACTIONS>
<ACTION value="microsoft.vsts.actions.checkin"/>
</ACTIONS>
</TRANSITION>
Retour au début
Détails des actions de transition
Utilisez des actions de transition d'état pour automatiser les transitions d'éléments de travail à différents points dans leur flux de travail. Vous pouvez tenir compte des détails d'utilisation suivants relatifs aux actions de transition :
Les actions de transition sont facultatives. Si l'état actuel de l'instance d'élément de travail a une entrée d'action pour l'action spécifiée, il retourne l'état « to ». Sinon, la valeur de retour est Null. Les intégrations doivent gérer correctement les valeurs de retour Null. C'est-à-dire :
ne pas faire échouer l'opération ;
conserver une trace ou un enregistrement qui indique que l'intégration n'a pas effectué de transition automatique car il lui manquait une action.
Pour chaque type d'élément de travail, les actions doivent être uniques pour les paires Etat/Action. Cela signifie que les auteurs de types d'éléments de travail ne peuvent pas spécifier plusieurs états « to » pour la même action.
Toutefois, plusieurs actions sur la même transition sont prises en charge pour permettre plusieurs intégrations de transition automatique, comme le montre l'exemple suivant :
<TRANSITION from="Working" to="Ready To Build"> <ACTIONS> <ACTION value="Microsoft.VSTS.Actions.Checkin"/> <ACTION value="ADatum.Actions.Complete"/> </ACTIONS> </TRANSITION>Les noms d'actions sont des noms de programmation pour lesquels vous pouvez utiliser uniquement des caractères anglais.
Les noms d'actions doivent respecter la même convention d'espaces de noms de références que les noms de références de champ pour éviter les conflits de nom d'action entre fournisseurs et clients. Toutefois, cette convention n'est pas appliquée par l'outil. Visual Studio ALM utilise Microsoft.VSTS.Actions.<your action>.
Vérification des erreurs de transition automatique
Les intégrateurs peuvent essayer deux types de transitions automatiques. Le premier est une transition automatique qui se produit suite à une action de l'utilisateur. Le second est une transition automatique qui se produit par automatisation sans assistance, par exemple une génération nocturne.
Transitions automatiques avec action de l'utilisateur Pour ce type de transition automatique, un utilisateur est présent pour réagir à tous les problèmes éventuels liés aux règles. Vous devez être sûr de gérer la situation qui se produit quand l'auteur d'un type d'élément de travail ajoute un champ obligatoire que l'intégration ne reconnaît pas. Pour ce faire, exécutez la transition automatique, puis analysez le type d'élément de travail pour rechercher des violations de règles. Si vous en trouvez, affichez le formulaire pour que l'utilisateur apporte des corrections.
Transitions automatiques avec automatisation sans assistance Vous devez supposer qu'aucun utilisateur n'est présent pour résoudre ces problèmes. Dans ce cas, l'intégration doit échouer normalement. Un journal des erreurs doit indiquer qu'une tentative de transition automatique a été effectuée et doit donner la raison de l'échec.
Lors de la définition d'un des types de transition automatique, définissez la transition de sorte que chaque élément de travail atteigne un état valide à la fin de la transition sans nécessiter une intervention de l'utilisateur. En d'autres termes, vous respectez toutes les règles qui sont définies pour l'état en cours de transition en fournissant des valeurs par défaut ou des valeurs copiées pour tous les champs. Si un champ devient non valide après la transition, la transition de l'état échoue.
Pour éviter que des champs deviennent non valides, procédez comme suit :
Définissez une valeur DEFAULTREASON pour la transition d'état.
Pour les champs qui deviennent obligatoires après la transition d'état, utilisez les éléments de règle DEFAULT ou COPY afin de spécifier une valeur pour le champ.
Supposons, par exemple, que vous avez créé l'archivage de l'action de transition, ce qui fait passer l'état d'un élément de travail de « Working » à « Ready to Build ». Les règles de l'élément de travail pour « Ready to Build » requièrent que le champ « ResolvedBy » soit défini. Vous définissez ensuite un élément de règle DEFAULT ou COPY pour « ResolvedBy » dans la section TRANSITION. En outre, vous définissez un élément DEFAULTREASON pour vérifier que le champ obligatoire peut être défini sans intervention de l'utilisateur.