Personnaliser un processus XML hébergé

  • Article

Azure DevOps Services

Azure DevOps Services prend en charge l’ajout et la mise à jour de processus via une expérience administrative qui est un processus d’importation basé sur le web. Après avoir ajouté un processus, vous pouvez créer un ou plusieurs projets à partir de celui-ci. Vous pouvez mettre à jour le processus à tout moment en l’important à nouveau. Les modifications apportées au modèle de processus sont ensuite appliquées à tous les projets qui utilisent le processus.

Important

Avec le modèle de processus XML hébergé, vous personnalisez le suivi du travail en mettant à jour certains fichiers de définition XML d’un modèle de processus. Cette fonctionnalité est disponible uniquement lorsque les données sont migrées vers Azure DevOps Services à l’aide du service d’importation de base de données Team Foundation Server.

Pour en savoir plus sur la personnalisation et les modèles de traitement, consultez Personnaliser le suivi du travail.

Un processus est un fichier zip qui contient un ensemble de fichiers interdépendants. Ces fichiers définissent les blocs de construction du système de suivi des éléments de travail et d’autres sous-systèmes dans Azure DevOps Services. Certains blocs de construction mettent à jour des projets existants, tandis que d’autres s’appliquent uniquement aux nouveaux projets. Consultez le tableau suivant pour obtenir la liste complète des blocs de construction.

Utilisé lors de l’importation/mise à jour d’un processus

Utilisé lors de la création d’un projet

Remplacé par les valeurs système par défaut

Ignoré

Suivi des éléments de travail

Esprits

Catégories

Configuration du processus

Zones et itérations

Gestion des tests

Éléments de travail

Requêtes d'élément de travail

Build

Lab Management

Gestion de version

Mappages Microsoft Project

Rapports

Portail (produits SharePoint)

Plug-ins et objets de processus pris en charge pour l’importation de processus

Il existe des différences entre ce que Azure DevOps Services prend en charge et ce que Team Foundation Server local prend en charge. Pour obtenir un résumé de ces différences, consultez Différences de personnalisations des modèles de processus.

Comment personnaliser un processus

Lorsque vous personnalisez un processus, il est plus facile de commencer par un processus bien défini que d’en créer un nouveau.

Si vous mettez à jour un processus existant que vous avez utilisé avec Team Foundation Server local, assurez-vous qu’il est conforme aux contraintes placées sur les modèles à importer.

Ouvrez Paramètres>Processus

Vous créez, gérez et personnalisez les processus à partir de Paramètres de l’organisation>Processus.

  1. Choisissez le logo Azure DevOps pour ouvrir Projets. Choisissez ensuite Paramètres de l’organisation.

    Ouverture de Paramètres de l’organisation.

  2. Ensuite, choisissez Processus.

    Paramètres de l’organisation, page Processus

    Important

    Si vous ne voyez pas Processus, vous travaillez à partir de TFS-2018 ou d’une version antérieure. La page Processus n’est pas prise en charge. Vous devez utiliser les fonctionnalités compatibles avec le modèle de processus XML local.

Exporter et importer un processus

  1. Sous l’onglet Processus , sélectionnez les points de suspension (...) pour ouvrir le menu contextuel du processus XML hébergé que vous souhaitez exporter. Vous pouvez exporter uniquement des processus XML hébergés.

    Option de menu Exporter le processus XML hébergé de la page > de processus

    Enregistrez le fichier zip et extrayez-en tous les fichiers.

  2. Renommez le processus dans le fichier ProcessTemplate.xml situé dans le répertoire racine.

    Nommez le processus pour le distinguer des processus existants.

    <name>MyCompany Agile Process </name>

    Modifiez le type de version et modifiez les nombres principaux et secondaires. Fournissez un GUID distinct pour le type, comme dans cet exemple :

    <version type="F50EFC58-C2FC-4C66-9814-E395D90778A3" major="1" minor="1"/>

  3. Appliquez les personnalisations prises en charge.

  4. Créez un fichier zip de tous les fichiers et dossiers dans le répertoire racine.

  5. Importez le fichier zip de votre processus personnalisé.

Personnalisations prises en charge

Vous pouvez appliquer les personnalisations suivantes à votre processus :

La section suivante répertorie les limitations imposées par le système.

Restrictions

Vous pouvez importer jusqu’à 32 processus dans Azure DevOps Services. Vos processus personnalisés doivent être conformes à toutes les règles résumées suivantes. Sinon, des messages d’erreur de validation peuvent apparaître lors de l’importation.

Modèle de processus

Votre fichier ProcessTemplate.xml doit être conforme à la syntaxe et aux règles décrites dans la référence d’élément XML ProcessTemplate. En outre, il doit remplir les conditions suivantes :

  • Limite le nombre de WIT définis à 64
  • Contient un seul fichier de définition de Categories.xml
  • Contient un seul fichier de définition de ProcessConfiguration.xml
  • Utilise des noms conviviaux uniques dans tous les champs et définitions WIT

En outre, votre processus doit réussir les vérifications de validation suivantes :

  • Les noms de processus sont uniques et contiennent au maximum 155 caractères Unicode.
    • Un modèle portant le même nom et le MÊME GUID de version qu’un processus existant remplace ce processus.
    • Un modèle portant le même nom, mais un GUID de version différente génère une erreur.
    • Les noms de processus ne peuvent pas contenir les caractères spéciaux suivants : . , ; ' ` : / \ * | ? " & % $ ! + = ( ) [ ] { } < >.
      Pour connaître les contraintes supplémentaires , consultez Restrictions d’affectation de noms.
  • Les dossiers de processus ne contiennent aucun fichier .exe. Même si vous pouvez importer un processus qui contient un fichier .exe, la création du projet échoue.
  • La taille totale du processus est au maximum de 2 Go. Sinon, la création du projet échoue.

Il traite la configuration

Le fichier de définition ProcessConfiguration.xml doit être conforme à la syntaxe et aux règles décrites dans la référence d’élément XML ProcessConfiguration. En outre, il doit remplir les conditions suivantes :

  • Spécifie tous les éléments TypeFields
  • Est limité à cinq backlogs de portefeuille
  • Contient un seul backlog de portefeuille non pris en charge
  • Spécifie un seul backlog de portefeuille parent pour chaque backlog de portefeuille subordonné
  • Contient les mappages d’état à méta-état de workflow requis et ne fait pas référence aux métastates non pris en charge

Catégories

Le fichier de définition Categories.xml doit être conforme à la syntaxe et aux règles décrites dans la référence d’élément XML Categories. En outre, il doit remplir les conditions suivantes :

  • Est limité à 32 catégories
  • Définit toutes les catégories référencées dans le fichier ProcessConfiguration.xml

Types d'éléments de travail

Un élément WITD et ses éléments enfants doivent être conformes à la syntaxe et aux règles décrites dans référence d’élément XML WITD. En outre, il doit remplir les conditions suivantes :

  • Il y a au maximum 512 champs dans un seul WIT et 512 champs sur tous les WIT.
  • Le nom convivial et l’attribut refname requis attribués à un WIT sont uniques dans l’ensemble des fichiers de définition WIT.
  • La valeur d’attribut refname requise ne contient pas de caractères non autorisés ou n’utilise pas les espaces de noms non autorisés System. Nom et Microsoft. Nom.
  • Les noms de référence contiennent au moins un point (.), et tous les autres caractères sont des lettres sans espaces.
  • L’élément WITD contient un élément FORM qui définit un élément WebLayout conforme à la syntaxe spécifiée dans les éléments WebLayout et Control.

Champs d'élément de travail

Un élément FIELDS et ses éléments enfants doivent être conformes à la syntaxe et aux règles décrites dans la référence d’élément XML FIELD. En outre, il doit remplir les conditions suivantes :

  • Le nom convivial et l’attribut refname requis attribués à un WIT sont uniques dans l’ensemble des fichiers de définition WIT.
  • La valeur d’attribut refname requise ne contient pas de caractères non autorisés ou n’utilise pas les espaces de noms non autorisés System. Nom et Microsoft. Nom.
  • Les noms de référence contiennent au moins un point (.), et tous les autres caractères sont des lettres sans espaces.

Un élément FIELD et ses éléments enfants peuvent contenir un élément GLOBALLIST .

Limiter les restrictions

  • Un élément FIELDS est limité à 512 champs.
  • Un type d’élément de travail est limité à 64 champs de nom de personne. Un champ person-name est un avec l’attribut et la valeur syncnamechanges=true.
  • Un élément ALLOWEDVALUES ou SUGGESTEDVALUES est limité à 512 éléments LISTITEM .
  • Un champ est limité à 1 024 règles.

Champs obligatoires

Les champs suivants sont spécifiés dans le fichier ProcessConfiguration.xml :

  • Pour tous les WIT d’une catégorie qui définit un backlog de configuration de processus, spécifiez les champs utilisés pour les attributs et les valeurs type=Team et type=Order.
  • Pour tous les WIT d’une catégorie qui définit un backlog ou un backlog de portefeuille standard, spécifiez le champ utilisé pour type=Effort.
  • Pour tous les WIT de la catégorie qui définit l’élément TaskBacklog , spécifiez :
    • Champ utilisé pour type=RemainingWork.
    • Champ utilisé pour type=Activity.
    • Règle ALLOWEDVALUES pour le champ utilisé pour type=Activity.

Restrictions de règle

En plus des restrictions de règle de champ standard, les restrictions suivantes sont appliquées :

  • Les éléments de règle de champ ne peuvent pas spécifier les attributs pour et pas .
  • Les éléments FIELD ne peuvent pas contenir les éléments de règle enfant CANNOTLOSEVALUE, NOTSAMEAS, MATCH et PROHIBITEDVALUES.
  • À l’exception des champs suivants, définitions DE CHAMP pour System. Les champs de nom ne peuvent pas contenir de règles de champ.
    • System.Title peut contenir les règles REQUIRED et DEFAULT.
    • System.Description peut contenir les règles REQUIRED et DEFAULT.
    • System.AssignedTo peut contenir les règles REQUIRED, DEFAULT, ALLOWEXISTINGVALUE et VALIDUSER.
    • System.ChangedBy peut contenir les règles REQUIRED, DEFAULT, ALLOWEXISTINGVALUE et VALIDUSER.

Noms et attributs cohérents

Dans un processus ou une collection de projets, le nom, le type et les autres attributs définis par un élément FIELD doivent être identiques dans toutes les définitions WIT.

champs d'identité

Les champs d’identité correspondent aux champs utilisés pour contenir des noms de compte, d’utilisateur ou de groupe. Les champs système principaux suivants sont codés en dur en tant que champs d’identité :

  • Assigned To (System.AssignedTo)
  • Authorized As (System.AuthorizedAs)
  • Changed By (System.ChangedBy)
  • Created By (System.CreatedBy)
  • Activated By (Microsoft.VSTS.Common.ActivatedBy)
  • Fermé par (Microsoft.VSTS.Common.ClosedBy)
  • Résolu par (Microsoft.VSTS.Common.ResolvedBy)
Ajouter un champ d’identité personnalisé

Un champ de chaîne est reconnu comme champ d’identité lorsque vous spécifiez l’attribut syncnamechanges sur True.

Restrictions de règle sur les champs d’identité

Pour la version actuelle de l’importation de processus, ne spécifiez aucune des règles suivantes dans une définition FIELD .

  • SUGGESTEDVALUES
  • Règles qui contiennent des valeurs de non-identité.
Exemple correct

Pour limiter les noms de compte valides dans un champ d’identité, spécifiez l’élément VALIDUSER avec un attribut de nom de groupe.

    <FIELD name="Project Manager" refname="Fabrikam.ProgramManager" type="String" reportable="dimension" syncnamechanges="true">
        <ALLOWEXISTINGVALUE />
        <VALIDUSER group="[PROJECT]\Program Manager Group" />
        <HELPTEXT>The program manager responsible for signing off on the user story.</HELPTEXT>
    </FIELD>

Avant d’importer le processus, vérifiez que vous avez créé le groupe dans les projets mis à jour par le processus.

Exemple incorrect

L’exemple suivant n’est pas valide, car il spécifie :

  • Élément ALLOWEDVALUES.
  • Élément DEFAULT qui spécifie la chaîne value="Not Assigned"de non-identité .
    <FIELD name="Project Manager" refname="Fabrikam.ProgramManager" type="String" reportable="dimension" syncnamechanges="true">
        <ALLOWEXISTINGVALUE />
        <ALLOWEDVALUES>
          <LISTITEM value="[PROJECT]\Program Manager Group" />
          <LISTITEM value="Not Assigned" />
        </ALLOWEDVALUES>
        <DEFAULT from="value" value="Not Assigned" />
        <VALIDUSER />
        <HELPTEXT>The program manager responsible for signing off on the user story.</HELPTEXT>
    </FIELD>

Workflow

Un élément WORKFLOW et ses éléments enfants doivent être conformes à la syntaxe et aux règles décrites dans référence d’élément XML WORKFLOW. En outre, il doit remplir les conditions suivantes :

  • Limite chaque WIT à 16 états de flux de travail
  • Définit tous les états de flux de travail mappés à des métaétats dans le fichier de définition ProcessConfiguration
  • Définit une transition entre tous les états de workflow mappés à la catégorie d’état « Proposé » et les états de workflow mappés à la catégorie d’état « InProgress »
  • Définit une transition entre tous les états de workflow mappés à la catégorie d’état « InProgress » et les états de workflow mappés à la catégorie d’état « Complete ».

Pour obtenir une description de la catégorie d’état et des mappages, consultez États de flux de travail et catégories d’état.

Listes globales

Pour le modèle de processus XML hébergé, les limites suivantes sont placées sur l’importation de liste globale :

  • Il existe au plus 64 listes globales.
  • Il y a au maximum 512 éléments par liste.
  • Environ 10 000 éléments peuvent être définis au total parmi toutes les listes globales spécifiées dans tous les WIT.

Présentation des formulaires

Un élément FORM et ses éléments enfants doivent être conformes à la syntaxe et aux règles décrites dans la référence d’élément XML FORM.

Un élément Control ne peut pas spécifier de contrôle personnalisé. Les contrôles personnalisés ne sont pas pris en charge.