Automatisation des 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.

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é "Résolu". L'auteur peut signifier Résolu, Fermé, Terminé, Prêt pour le test, Inclure dans la build, etc. On pourrait demander à tous les auteurs de type d'élément de travail d'inclure un état explicitement nommé "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 à 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, 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 Suivi des éléments de travail, cet outil doit exécuter les tâches suivantes :

1. Déterminer l'état vers lequel l'élément de travail doit transiter lorsque l'action est exécutée.

2. Attribuer à l'élément de travail l'état "to".

   L'API de suivi des éléments de travail fournit des méthodes d'exécution de 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 : Team Foundation Server SDK.

   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 des 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 soit prêt pour la build 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 de leur flux de travail. Vous pouvez tenir compte des détails d'utilisation suivants concernant les 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 "à". Si tel n'est pas le cas, la valeur de retour est Null. Les intégrations doivent harmonieusement gérer les valeurs de retour Null. C'est-à-dire :

  • Ne faites pas échouer l'opération.

  • Conservez 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 "à" 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 programmations 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>.

Retour au début

Vérification des erreurs de transition automatique

Les intégrateurs peuvent essayer deux types de transition automatiques. La première est une transition automatique qui se produit suite à une action de l'utilisateur. La seconde est une transition automatique qui se produit par automation 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 relatifs aux règles. Vous devez être certain de prendre en charge le cas qui se produit lorsque l'auteur d'un type d'élément de travail ajoute un champ obligatoire que l'intégration ne reconnaît pas. Pour prendre en charge cette situation, 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 automation 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 de façon normale. Un journal des erreurs doit indiquer qu'une tentative de transition automatique a été effectuée et doit donner la raison de la défaillance.

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 les 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.

Par exemple, vous avez créé l'archivage de l'action de transition 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 le champ "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.

Retour au début

Voir aussi

Concepts

Quand et où appliquer une règle de champ

Associating a State Transition with an Action

Historique des modifications