Automatisation des transitions d'état
Mise à jour : novembre 2007
Clients et partenaires peuvent décider de faire transiter automatiquement des éléments de travail d'un état à un autre en fonction d'événements qui se produisent ailleurs dans Microsoft Visual Studio Team System ou en dehors de Microsoft Visual Studio Team System, par exemple 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.
Remarque : |
---|
L'API de suivi des éléments de travail fait partie du Kit de développement logiciel (SDK) Visual Studio Team System disponible sur le site Web Microsoft. |
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".
Mais cette solution est trop restrictive et peu satisfaisante, d'un point de vue international, parce qu'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 section
Association d'une transition d'état à une action
Automatisation des transitions
Détails des actions de transition
Vérification des erreurs de transition automatique
Rubriques connexes
Voir aussi
Concepts
Définition de la portée des règles des champs par État, Transition ou Raison