Valider et résoudre les erreurs liées aux modèles de processus

  • Article

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Dans le cadre du processus d’importation de migration, l’outil de migration de données case activée le processus utilisé par les projets dans la collection. Corrigez les erreurs qui sont signalées.

Après avoir résolu les erreurs, réexécutez la commande de l’outil de migration de validate données pour vérifier que toutes les erreurs ont été corrigées.

Remarque

Il est recommandé d’utiliser le Guide de migration pour progresser dans votre importation. Le guide fournit des liens vers la documentation technique en fonction des besoins.

Avec la publication d’Azure DevOps Server 2019, le service d’importation de base de données TFS a été renommé pour migrer vers Azure DevOps. Cela inclut TfsMigrator devenant l’outil de migration de données ou de migration en abrégé. Ce service fonctionne toujours exactement comme l’ancien service d’importation. Si vous utilisez une ancienne version locale avec TFS comme personnalisation, vous pouvez toujours utiliser cette fonctionnalité pour migrer vers Azure DevOps tant que vous effectuez une mise à niveau vers l’une des versions prises en charge.

Types de validation de processus

Pendant la validation, l’outil de migration de données détermine le modèle de processus cible pour chaque projet. Il affecte automatiquement l’un des deux modèles de processus suivants à chaque projet de la collection :

  • Modèle de processus hérité : si le projet a été créé avec le modèle de processus Agile, Scrum ou CMMI et n’a jamais été personnalisé.
  • Modèle de processus XML hébergé : si le processus de projet semble avoir été personnalisé. Un processus personnalisé contient des champs personnalisés, des types d’éléments de travail ou d’autres types de personnalisations.

Lorsque le processus XML hébergé est le modèle de processus ciblé, l’outil de migration de données valide si les personnalisations peuvent être migrées. L’outil de migration de données génère deux fichiers pendant la validation :

  • DataMigrationTool.log : contient l’ensemble d’erreurs de validation de processus trouvées dans la collection. Corrigez toutes les erreurs de processus trouvées pour poursuivre votre migration.

  • TryMatchOobProcesses.log : répertorie pour chaque projet le modèle de processus cible - Héritage ou XML hébergé. Pour les projets qui sont définis pour cibler le modèle de processus XML hébergé, il explique pourquoi ils sont considérés comme personnalisés. Vous n’avez pas à corriger ces erreurs, mais elles vous donnent des conseils au cas où vous souhaitez migrer vers le modèle de processus d’héritage. Notez qu’une fois qu’une collection est importée, vous pouvez migrer un projet vers un modèle de processus d’héritage.

La plupart des clients ont un mélange de projets au sein d’une collection. Certains projets utilisent un modèle de processus par défaut et d’autres utilisent des modèles de processus personnalisés. L’outil de migration de données case activée et valide chaque projet en conséquence. Il est très possible que vous disposiez d’un mélange de projets, certains mappés à un processus hérité et d’autres à un processus XML hébergé.

Nous vous recommandons d’examiner les TryMatchOobProcesses.log pour tous les projets qui n’ont pas été personnalisés, afin de déterminer s’il existe des erreurs. Si c’est le cas, effectuez les ajustements en conséquence afin que le projet puisse être mappé à un processus hérité lors de l’importation des données.

Mise à jour vers un processus système

Si vous avez commencé avec une version antérieure d’Azure DevOps Server, les chances que vos projets utilisent toujours un modèle de processus plus ancien. Si ces projets n’ont pas été mis à jour à l’aide de l’Assistant Configurer les fonctionnalités, l’outil de migration de données trouve des erreurs de processus. Dans certains cas rares, si votre processus est très ancien, même l’Assistant Configurer les fonctionnalités ne pourra pas résoudre les erreurs.

Voici quelques exemples de messages d’erreur que vous pouvez recevoir :

Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element PortfolioBacklog is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element BugWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element FeedbackRequestWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element FeedbackResponseWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Team.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField RemainingWork.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Order.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Effort.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Activity.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationStartInformation.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationLaunchInstructions.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationType.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF400572: The Project Process Settings must be configured for this feature to be used.

Si vous n’avez jamais personnalisé votre projet (champs ajoutés, types d’éléments de travail, etc.), la correction de ces erreurs est en fait assez simple. Si vous avez personnalisé votre processus, cette approche ne fonctionnera pas. Vous devez modifier manuellement les modèles de processus afin que vos personnalisations ne soient pas remplacées.

Tout d’abord, assurez-vous de connaître le processus que votre projet a démarré. Est-ce Scrum, Agile ou CMMI ? Dans cet exemple, supposons Agile. Ensuite, accédez aux scripts de personnalisation de processus fournis sur GitHub et téléchargez le dépôt. Dans cette instance, nous allons nous concentrer sur le contenu dans le dossier Importer .

Utilisez le script ConformProject.ps1 pour conformer un projet de votre choix au processus système Agile. Cela met à jour l’ensemble du projet pour qu’il soit Agile.

.\ConformProject.ps1 "<collection url>" "<project name>" "c:\process-customization-scripts\import\agile"

Assurez-vous que vous effectuez cette opération pour chaque projet et chaque projet.

Résoudre les erreurs de processus

Vos modèles de processus sont-ils personnalisés ? Utilisez-vous un modèle de processus obsolète plus ancien ? Dans ce cas, vous aurez probablement des erreurs de validation de processus. L’outil de migration de données effectue une case activée exhaustive par rapport à vos modèles de processus. Il case activée s de s’assurer qu’il est valide pour Azure DevOps Services. Les chances sont que vous devrez effectuer des ajustements et les appliquer à votre collection.

Remarque

Si vous utilisez un processus OOB Agile, Scrum ou CMMI, vous ne verrez probablement aucune erreur dans le DataMigrationTool.log. Au lieu de cela, case activée le TryMatchOobProcesses.log pour les erreurs. Si vous êtes libre d’erreur, votre projet est mappé à un processus OOB.

Il existe plusieurs personnalisations qui ne fonctionnent pas dans Azure DevOps Services. Veillez à consulter la liste des personnalisations prises en charge.

Si vous avez des projets qui utilisent un modèle de processus plus ancien, l’outil de migration de données trouve plusieurs erreurs. Cela est dû au fait que vos modèles de processus n’ont pas été mis à jour pour correspondre aux modèles de processus les plus récents. Pour commencer, essayez d’exécuter l’Assistant Configurer les fonctionnalités pour chaque projet. Cela tentera de mettre à jour vos modèles de processus avec les fonctionnalités les plus récentes. Cela devrait réduire considérablement le nombre d’erreurs.

Enfin, assurez-vous que vous disposez witadmin sur l’ordinateur que vous envisagez d’utiliser pour corriger les erreurs de processus. Il peut s’agir de votre bureau local. L’outil witadmin en ligne de commande est utilisé dans les scripts automatisés et est requis chaque fois que vous apportez des modifications aux modèles de processus.

Étape 1 - Examiner les erreurs

DataMigrationTool.log fichier sera généré et contient la liste des erreurs détectées par le processus de validation. Pour afficher les journaux, ouvrez DataMigrationTool.log fichier. Recherchez la chaîne « Validation - Démarrage de la validation du projet 1 ». Chaque projet est validé. Analysez tous les projets et recherchez toutes les lignes qui contiennent un préfixe [ Erreur ....

Traiter le fichier de journalisation généré par l’outil de migration de données

Pour obtenir la liste des erreurs de validation, consultez Résoudre les erreurs de validation pour l’importation de processus. Pour chaque erreur de validation, nous avons fourni le numéro d’erreur, la description et la méthode à résoudre.

Étape 2 - Corriger les erreurs

Une fois que vous avez déterminé quels projets ont des erreurs et les détails de l’erreur, corrigez les erreurs. La résolution des erreurs nécessite de modifier la syntaxe XML et d’appliquer les modifications au projet.

Remarque

Nous vous recommandons de ne pas utiliser TFS Power Tools pour effectuer ce travail. Au lieu de cela, nous vous recommandons vivement de modifier manuellement le code XML.

Pour obtenir le modèle de processus à partir du projet, ajoutez le paramètre /SaveProcesses lors de l’exécution de la commande de l’outil de migration de données.

Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region} /SaveProcesses

Cette commande extrait le code XML du projet et le place dans le même dossier que les journaux. Extrayez les fichiers zip sur votre ordinateur local pour pouvoir modifier les fichiers.

À présent, corrigez le code XML. Utilisez les journaux d’activité du DataMigrationTool.log fichier pour déterminer les erreurs pour chaque projet.

Traiter le fichier de journalisation généré par l’outil de migration de données

Certaines erreurs vous obligeront à utiliser une witadmin changefield commande. La modification d’un nom de champ est l’exemple le plus courant. Pour gagner du temps, nous vous recommandons d’exécuter la witadmin changefield commande, puis de réexécuter l’outil de migration de données. Pour ce faire, réexportez le code XML avec les noms corrigés. Sinon, vous devez corriger manuellement les champs de la syntaxe XML.

Une fois que vous avez apporté un correctif, appliquez les modifications au serveur Azure DevOps. Pour ce faire, selon les modifications que vous avez apportées, vous devez exécuter une ou plusieurs witadmin commandes. Pour faciliter cette opération, nous avons créé un script PowerShell pour automatiser le processus. Le script contient toutes les witadmin commandes nécessaires à la conformité de l’ensemble du processus.

Vous pouvez obtenir les scripts au niveau des scripts de personnalisation de processus. Utilisez le script import/ConformProject.ps1 .

.\conformproject.ps1 "<collection url>" "<project name>" "<process template folder>"

Script de processus de projet conformes en cours d’exécution

Une fois le script terminé, réexécutez l’outil de migration de données pour valider la collection. Suivez les étapes 1 à 3 jusqu’à ce que l’outil de migration de données ne génère plus d’erreurs de validation.

Conseil

Si vous débutez avec XML et witadminque nous vous suggérons d’apporter un correctif à la fois, puis de vous conformer. Poursuivez cette boucle jusqu’à ce que toutes les erreurs soient résolues.

Erreurs de validation courantes

VS402841 : le champ X dans le type d’élément de travail Bogue contient syncnamechanges=false, mais a des règles qui en font un champ d’identité. Les champs d’identité doivent avoir syncnamechanges=true. Mettez à jour votre modèle de processus pour inclure cette modification.

Dans Azure DevOps Services, nous avons ajouté une règle afin que chaque champ d’identité ait l’attribut syncnamechanges=true . Dans Azure DevOps Server, cette règle ne s’applique pas. Par conséquent, l’outil de migration de données identifie cela comme un problème. Ne vous inquiétez pas, l’application de cette modification sur Azure DevOps Server locale ne cause aucun préjudice.

Exécutez la commande witadmin changefield. La syntaxe de la commande ressemble à ce qui suit :

witadmin changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /syncnamechanges:true

Pour plus d’informations sur la witadmin changefield commande, consultez Gérer les champs d’élément de travail.

TF402556 : Pour que system.itérationId soit bien défini, vous devez le nommer ID d’itération et définir son type sur Integer.

Cette erreur est généralement utilisée pour les anciens modèles de processus. Essayez d’exécuter l’Assistant Configurer les fonctionnalités sur chaque projet. Vous pouvez également exécuter la commande suivante witadmin :

witadmin changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /name:newname

TF402571 : l’élément Requis BugWorkItems est manquant dans Process Configuration.

Cette erreur se produit généralement lorsqu’un processus n’a pas été mis à jour en un certain temps. Essayez d’exécuter l’Assistant Configurer des fonctionnalités sur chaque projet à résoudre.

TF402564 : vous avez défini des listes globales XX. Seuls 64 sont autorisés.

Par défaut, Azure DevOps Services prend en charge 64 listes globales. Vous allez généralement exécuter cette erreur si vous avez une grande quantité de pipelines de build. La liste globale nommée Builds - TeamProjectName est créée pour chaque nouveau pipeline de build. Vous devez supprimer les listes globales obsolètes.