Partage via

Valider et préparer l’environnement serveur pour la migration

  • Article

La validation implique la préparation de votre environnement Azure DevOps Server mis à niveau pour la migration. Cet article vous aide à résoudre les problèmes courants. S’il n’y a pas d’erreurs et que toutes les case activée de validation sont passées, la collection de projets de votre équipe est prête et vous pouvez passer à la phase suivante. Examinez les fichiers journaux pour rechercher des erreurs si toutes les case activée passées.

Diagramme de l’étape Valider mise en surbrillance des sept étapes de la migration.

Prérequis

Téléchargez la dernière version de l’outil de migration de données.

Découvrir les 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 Capability Maturity Model Integration (CMMI) et n’a jamais été personnalisé.
  • Modèle de processus XML hébergé : si le processus de projet semble être 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 des 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. Une fois qu’une collection est migrée, vous pouvez migrer un projet vers un modèle de processus d’héritage.

Valider une collection de projets d’équipe

Étant donné que chaque collection de projets d’équipe correspond à sa propre base de données SQL, le processus de validation examine différents aspects de votre collection, notamment :

  • Taille de votre base de données de collection
  • Classement de la base de données SQL
  • Identités des utilisateurs dans la collection
  • Personnalisations de modèle (processus)

Pour démarrer la validation, utilisez l’outil de migration. Nous vous recommandons d’exécuter l’outil de migration à partir de l’un des serveurs de niveau Application (AT) dans votre environnement Azure DevOps Server.

Pour obtenir des options de ligne de commande spécifiques, demandez du texte d’aide à l’aide de la commande suivante :

	Migrator validate /help

Le moyen le plus courant de démarrer la validation consiste à spécifier l’URL de la collection de projets d’équipe avec la structure suivante :

	Migrator validate /collection:http://localhost:8080/tfs/DefaultCollection

Afficher les avertissements et erreurs de validation

Une fois l’outil de migration terminé, il génère des fichiers journaux et des résultats affichés sur l’écran d’invite de commandes. Si aucune erreur ne se produit et que toutes les case activée de validation passent, votre collection de projets d’équipe est prête pour la phase suivante. Si la validation case activée échoue, passez en revue les fichiers journaux pour identifier les erreurs, puis résolvez-les.

Concentrez-vous sur le Migrator.log fichier, qui contient des détails essentiels sur les case activée de validation et vous aide à conserver la personnalisation. Les autres fichiers correspondent à des erreurs de validation spécifiques en fonction de leurs noms. 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 de [Error...

En outre, les TryMatchOobProcesses.log erreurs liées aux projets qui utilisent des processus OOB (Out-of-Box) (tels que Agile, Scrum ou CMMI). Si un projet utilise un processus OOB sans personnalisations, le projet est inclus dans le modèle hérité. Il est important de noter que les erreurs dans ce fichier n’entravent pas le processus de migration.

Capture d’écran du fichier DataMigrationTool.log 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 chaque erreur de validation, nous avons fourni le numéro d’erreur, la description et la méthode à résoudre. Différents types d’erreurs peuvent apparaître dans les journaux de validation case activée. Demandez de l’aide auprès de votre partenaire DevOps formé, des services de conseil Microsoft ou du support Microsoft Premier pour résoudre les erreurs rencontrées.

Résoudre les erreurs de modèle de processus

Les erreurs principales que nous trouvons sont des problèmes de modèle de processus. Ces problèmes proviennent de projets d’équipe obsolètes qui n’intègrent pas les dernières fonctionnalités d’Azure DevOps Server ou les personnalisations non prises en charge par Azure DevOps Services. Toutefois, Azure DevOps Services prend en charge une gamme de personnalisations, et la validation indique uniquement celles nécessitant une prémigration de résolution. L’outil de migration de données effectue une case activée complète de vos modèles pour la compatibilité d’Azure DevOps Services, mais certaines modifications peuvent être nécessaires.

  • Les modèles de processus personnalisés ou les modèles obsolètes peuvent entraîner des erreurs de validation de processus lors de la migration.
  • Si vous utilisez un processus OOB Agile, Scrum ou CMMI, case activée les TryMatchOobProcesses.log erreurs. Les projets sans erreur correspondent aux processus OOB.
  • Certaines personnalisations ne fonctionnent pas dans Azure DevOps Services. Passez en revue la liste de personnalisations prise en charge.
  • Pour les projets utilisant des modèles plus anciens, exécutez l’Assistant Configurer les fonctionnalités pour mettre à jour des modèles avec des fonctionnalités récentes et réduire le nombre d’erreurs.
  • Vérifiez qu’il est disponible sur l’ordinateur où vous corrigez witadmin les erreurs de processus. Il est essentiel d’apporter des modifications aux modèles de processus.

Tenez compte des outils suivants pour résoudre les erreurs de processus :

  • Utilisez l’outil en ligne de commande witadmin.exe inclus dans les installations de Visual Studio. Une documentation technique détaillée sur la résolution de ces erreurs est disponible sur ce lien.
  • Automatisez l’exportation de modèles de processus pour chaque projet d’équipe à l’aide d’une commande d’outil de migration non documentée : Migration valide /collection :http://localhost:8080/tfs/DefaultCollection /SaveProcesses.
  • Explorez le Gestionnaire de projet d’équipe TFS sur GitHub (lien). Il vous permet de comparer des projets d’équipe avec des modèles de processus connus, y compris des modèles prêtes à l’emploi.

Pour corriger les erreurs, modifiez la syntaxe XML et appliquez les modifications au projet.

Conseil

Nous vous recommandons de modifier manuellement le code XML, plutôt que d’utiliser TFS Power Tools.

Pour obtenir le modèle de processus à partir du projet, ajoutez le /SaveProcesses paramètre lorsque vous exécutez la commande 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 fichier DataMigrationTool.log pour déterminer les erreurs pour chaque projet.

Capture d’écran du fichier de journalisation de processus généré par l’outil de migration de données.

Certaines erreurs vous obligent à 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 commande witadmin changefield , puis de réexécuter l’outil de migration de données. Cette opération réexporte le code XML avec les noms corrigés. Sinon, corrigez manuellement les champs de la syntaxe XML.

Une fois que vous avez apporté un correctif, appliquez les modifications au serveur Azure DevOps. Selon les modifications que vous avez apportées, vous devez exécuter une ou plusieurs commandes witadmin. Nous avons créé un script PowerShell pour automatiser ce processus. Le script contient toutes les commandes witadmin nécessaires pour confirmer l’intégralité 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>"

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.

Capture d’écran du processus de projet conforme dans PowerShell.

Conseil

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

Mise à jour vers un processus système

Si vous avez commencé avec une version antérieure d’Azure DevOps Server, vos projets utilisent probablement 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 détecte les erreurs de processus. Dans de rares cas, même l’Assistant peut ne pas résoudre les anciens problèmes liés au processus.

Vous pouvez recevoir certains des exemples de messages d’erreur suivants :

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 pas personnalisé votre projet (par exemple, les champs ajoutés, les types d’éléments de travail, et ainsi de suite).), la résolution de ces erreurs est simple. Toutefois, si vous avez personnalisé votre processus, cette approche ne suffit pas. Vous devez ajuster manuellement les modèles de processus pour conserver vos personnalisations d’être remplacées.

Pour aligner votre processus, procédez comme suit pour chaque projet :

  1. Identifiez le processus initial que votre projet a démarré avec (Scrum, Agile ou CMMI).
  2. Visitez les scripts de personnalisation de processus sur GitHub et téléchargez le référentiel.
  3. Concentrez-vous sur le contenu du dossier Migration.
  4. Utilisez le script suivant ConformProject.ps1 pour aligner un projet de votre choix avec le processus système Agile. Cette action met à jour l’ensemble du projet pour qu’il soit Agile.
.\ConformProject.ps1 "<collection url>" "<project name>" "c:\process-customization-scripts\import\agile"

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 pour 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 ce problème. L’établissement de cette modification sur Azure DevOps Server en local n’entraîne aucun préjudice.

Exécutez la commande witadmin changefield . La syntaxe de la commande ressemble à l’exemple suivant.

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

Pour plus d’informations sur la commande witadmin changefield , 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 souvent associée aux modèles de processus obsolètes. Pour y remédier, vous pouvez exécuter l’Assistant Configurer les fonctionnalités pour chaque projet. Vous pouvez également exécuter la commande suivante pour automatiser le processus.

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 est généralement observée lorsqu’un processus n’a pas été mis à jour pendant un certain temps. Pour résoudre ce problème, exécutez l’Assistant Configurer les fonctionnalités pour chaque projet.

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

Azure DevOps Services prend en charge en mode natif 64 listes globales. Cette erreur se produit généralement lorsqu’il existe un grand nombre de pipelines de build, car chaque nouveau pipeline crée une liste globale nommée Builds - TeamProjectName. Pour résoudre cette erreur, supprimez les listes globales obsolètes.

Répéter les case activée de validation

Dans chaque itération, résolvez les erreurs et effectuez des case activée de validation pour les résoudre, comme indiqué par les fichiers journaux de validation. Conservez ce cycle jusqu’à ce que toutes les erreurs soient rectifiées et vous recevez la confirmation que la validation de regroupement case activée s réussit.

Étapes suivantes

Préparer l’exécution des tests