Partager via

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 les 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 processus, 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 les 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 des processus

Zones et itérations

Gestion des tests

Éléments de travail

Requêtes d’élément de travail

Build

Lab Management

Gestion des versions

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 qu’Azure DevOps Services prend en charge et ce que Team Foundation Server prend en charge localement. Pour obtenir un résumé de ces différences, consultez les différences de personnalisations des modèles de processus.

Comment personnaliser un processus

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

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

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.

    Ouvrir les 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 ne pouvez exporter que des processus XML hébergés.

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

    Enregistrez le fichier zip et extrayez tous les fichiers de celui-ci.

  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, elle doit respecter les conditions suivantes :

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

En outre, votre processus doit passer 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érent génère une erreur.
    • Les noms de processus ne peuvent pas contenir les caractères spéciaux suivants : . , ; ' ` : / \ * | ? " & % $ ! + = ( ) [ ] { } < >.
      Consultez les restrictions d’affectation de noms pour obtenir des contraintes supplémentaires.
  • Les dossiers de traitement 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 d’au plus 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, elle doit respecter 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étastate de flux de travail requis et ne fait pas référence à des 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 Categories XML. En outre, elle doit respecter 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 la référence d’élément XML WITD. En outre, elle doit respecter les conditions suivantes :

  • Il existe au maximum 512 champs au sein d’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 de fichiers de définition WIT.
  • La valeur d’attribut refname requise ne contient pas de caractères interdits 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éments 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 FIELD XML. En outre, elle doit respecter les conditions suivantes :

  • Le nom convivial et l’attribut refname requis attribués à un WIT sont uniques dans l’ensemble de fichiers de définition WIT.
  • La valeur d’attribut refname requise ne contient pas de caractères interdits 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 .

Restrictions de limite

  • 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 nom de personne est un champ 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 régulier, 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

Outre les 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 non les attributs.
  • 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 FIELD 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, un nom, un type et d’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 de base suivants sont codés en dur en tant que champs d’identité :

  • Affecté à (System.AssignedTo)
  • Autorisé en tant que (System.AuthorizedAs)
  • Modifié par (System.ChangedBy)
  • Créé par (System.CreatedBy)
  • Activé par (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 comme 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 .

  • SUGGESTIONSVALUES
  • Règles qui contiennent des valeurs non-identités.
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"non-identity .
    <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 la référence d’élément XML WORKFLOW. En outre, elle doit respecter les conditions suivantes :

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

Pour obtenir une description des catégories et mappages d’état, consultez les états de flux de travail et les 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 maximum 64 listes globales.
  • Il y a au maximum 1 024 éléments par liste.
  • Environ 10 000 éléments peuvent être définis au total parmi toutes les listes globales qui sont spécifiées sur 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 FORM XML.

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