Verifiera och lösa fel som rör processmallar

  • Artikel

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

Som en del av migreringsprocessen kontrollerar datamigreringsverktyget den process som används av projekten i samlingen. Åtgärda eventuella fel som flaggas.

När du har löst felen kör du datamigreringsverktygets validate kommando igen för att kontrollera att alla fel har åtgärdats.

Kommentar

Vi rekommenderar att du använder migreringsguiden för att fortsätta med importen. Guiden länkar till den tekniska dokumentationen efter behov.

I och med lanseringen av Azure DevOps Server 2019 omprofilerades TFS Database Import Service till Migrate to Azure DevOps. Detta inkluderar att TfsMigrator blir datamigreringsverktyget eller migratorn för kort. Den här tjänsten fungerar fortfarande på exakt samma sätt som den gamla importtjänsten. Om du har en äldre version av lokalt med TFS som varumärke kan du fortfarande använda den här funktionen för att migrera till Azure DevOps så länge du uppgraderar till någon av de versioner som stöds.

Processverifieringstyper

Under valideringen avgör datamigreringsverktyget målprocessmodellen för varje projekt. Den tilldelar automatiskt en av följande två processmodeller till varje projekt i samlingen:

  • Ärvd processmodell: Om projektet skapades med processmallen Agile, Scrum eller CMMI och aldrig anpassades.
  • Värdbaserad XML-processmodell: Om projektprocessen verkar ha anpassats. En anpassad process innehåller anpassade fält, arbetsobjektstyper eller andra typer av anpassningar.

När den värdbaserade XML-processen är målprocessmodellen verifierar datamigreringsverktyget om anpassningarna kan migreras. Datamigreringsverktyget genererar två filer under valideringen:

  • DataMigrationTool.log: Innehåller den uppsättning processvalideringsfel som hittades i samlingen. Åtgärda alla processfel som hittades för att fortsätta med migreringen.

  • TryMatchOobProcesses.log: Listor för varje projekt målprocessmodellen – Arv eller värdbaserad XML. För projekt som är inställda på att rikta in sig på den värdbaserade XML-processmodellen förklarar den varför de anses vara anpassade. Du behöver inte åtgärda dessa fel, men de ger vägledning om vad du ska göra om du vill migrera till arvsprocessmodellen. Observera att när en samling har importerats kan du migrera ett projekt till en arvsprocessmodell.

De flesta kunder har en blandning av projekt i en samling. Vissa projekt använder en standardprocessmall och andra använder anpassade processmallar. Datamigreringsverktyget kontrollerar och validerar varje projekt i enlighet med detta. Det är mycket möjligt att du har en blandning av projekt, vissa mappade till en ärvd process och andra till en värdbaserad XML-process.

Vi rekommenderar att du granskar TryMatchOobProcesses.log för alla projekt som inte har anpassats för att avgöra om det finns några fel. I så fall gör du justeringarna så att projektet kan mappas till en ärvd process vid dataimport.

Uppdatera till en systemprocess

Om du började med en äldre version av Azure DevOps Server använder dina projekt fortfarande en äldre processmall. Om dessa projekt inte har uppdaterats med hjälp av guiden Konfigurera funktioner hittar datamigreringsverktyget processfel. I vissa sällsynta fall kan inte ens guiden Konfigurera funktioner lösa felen om processen är mycket gammal.

Här är några exempel på felmeddelanden som du kan få:

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.

Om du aldrig har anpassat projektet (tillagt fält, typer av arbetsobjekt osv.) är det faktiskt ganska enkelt att åtgärda dessa fel. Om du har anpassat processen fungerar inte den här metoden. Du måste ändra processmallarna manuellt så att dina anpassningar inte skrivs över.

Kontrollera först vilken process projektet startade som. Är det Scrum, Agile eller CMMI? I det här exemplet ska vi anta Agile. Gå sedan till processanpassningsskripten som tillhandahålls på GitHub och ladda ned lagringsplatsen. I det här fallet ska vi fokusera på innehållet i mappen Import .

Använd skriptet ConformProject.ps1 för att anpassa ett projekt som du väljer till den agila systemprocessen. Detta uppdaterar hela projektet så att det blir agilt.

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

Se till att du gör detta för varje projekt.

Åtgärda processfel

Är dina processmallar anpassade? Använder du en äldre inaktuell processmall? I så fall har du förmodligen processvalideringsfel. Datamigreringsverktyget gör en fullständig kontroll mot dina processmallar. Den kontrollerar att den är giltig för Azure DevOps Services. Oddsen är att du måste göra vissa justeringar och tillämpa dem på din samling.

Kommentar

Om du använder en OOB Agile-, Scrum- eller CMMI-process ser du förmodligen inga fel i DataMigrationTool.log. Kontrollera i stället TryMatchOobProcesses.log efter fel. Om du är felfri mappas projektet till en OOB-process.

Det finns flera anpassningar som inte fungerar i Azure DevOps Services. Kontrollera att du granskar listan över anpassningar som stöds.

Om du har projekt som använder en äldre processmall hittar datamigreringsverktyget flera fel. Det beror på att dina processmallar inte har uppdaterats för att matcha de senaste processmallarna. Börja genom att prova att köra guiden Konfigurera funktioner för varje projekt. Detta kommer att försöka uppdatera dina processmallar med de senaste funktionerna. Om du gör det bör du minska antalet fel drastiskt.

Kontrollera slutligen att du har witadmin på datorn som du tänker använda för att åtgärda processfelen. Det här kan vara ditt lokala skrivbord. Kommandoradsverktyget witadmin används i de automatiserade skripten och krävs när du gör ändringar i processmallarna.

Steg 1 – Granska fel

DataMigrationTool.log filen genereras och innehåller listan över fel som valideringsprocessen hittade. Om du vill visa loggarna öppnar du DataMigrationTool.log fil. Sök efter strängen "Validation – Starting validation of project 1". Varje projekt verifieras. Sök igenom alla projekt och sök efter alla rader som innehåller prefixet [Fel ....

Processloggningsfil som genereras av datamigreringsverktyget

En lista över valideringsfel finns i Lösa valideringsfel för processimport. För varje valideringsfel har vi angett felnumret, beskrivningen och metoden som ska matchas.

Steg 2 – Åtgärda fel

När du har fastställt vilka projekt som har fel och felinformation kan du åtgärda felen. För att åtgärda felen måste du ändra XML-syntaxen och tillämpa ändringarna i projektet igen.

Kommentar

Vi rekommenderar att du inte använder TFS Power Tools för att utföra det här arbetet. I stället rekommenderar vi starkt att du ändrar XML manuellt.

Om du vill hämta processmallen från projektet lägger du till parametern /SaveProcesses när du kör kommandot för datamigreringsverktyget.

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

Det här kommandot extraherar XML-koden från projektet och placerar den i samma mapp som loggarna. Extrahera zip-filerna till den lokala datorn så att du kan redigera filerna.

Åtgärda xml-koden nu. Använd loggarna DataMigrationTool.log från filen för att fastställa felen för varje projekt.

Processloggningsfil som genereras av datamigreringsverktyget

Vissa fel kräver att du använder ett witadmin changefield kommando. Att ändra ett fältnamn är det vanligaste exemplet. För att spara lite tid rekommenderar vi att du kör witadmin changefield kommandot och sedan kör datamigreringsverktyget igen. Om du gör det exporteras XML:en igen med de korrigerade namnen. Annars måste du även manuellt åtgärda fälten i XML-syntaxen.

När du har åtgärdat det tillämpar du ändringarna på Azure DevOps Server igen. För att göra detta måste du, beroende på vilka ändringar du har gjort, köra ett eller flera witadmin kommandon. För att göra det här enklare för dig skapade vi ett PowerShell-skript för att automatisera processen. Skriptet innehåller alla witadmin kommandon som behövs för att följa hela processen.

Du kan hämta skripten i Bearbeta anpassningsskript. Använd skriptet import/ConformProject.ps1 .

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

Anpassa projektprocessskript som körs

När skriptet har slutförts kör du datamigreringsverktyget igen för att verifiera samlingen. Följ steg 1 till 3 tills datamigreringsverktyget inte genererar fler valideringsfel.

Dricks

Om du är nybörjare på XML och witadminföreslår vi att du gör en korrigering i taget och sedan följer den. Fortsätt med den här loopen tills alla fel har lösts.

Vanliga valideringsfel

VS402841: Fält X i arbetsobjektstypen Bugg har syncnamechanges=false men har regler som gör det till ett identitetsfält. Identitetsfält måste ha syncnamechanges=true. Uppdatera processmallen så att den innehåller den här ändringen.

I Azure DevOps Services har vi lagt till en regel så att varje identitetsfält måste ha attributet syncnamechanges=true . I Azure DevOps Server gäller inte den regeln. Därför identifierar datamigreringsverktyget detta som ett problem. Oroa dig inte, att göra den här ändringen på Azure DevOps Server lokalt orsakar ingen skada.

Kör kommandot witadmin changefield. Syntaxen för kommandot ser ut ungefär så här:

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

Mer information om kommandot finns i witadmin changefield Hantera arbetsobjektfält.

TF402556: För att fältet System.IterationId ska vara väldefinierat måste du ge det namnet Iteration ID och ange dess typ till Heltal.

Det här felet är typiskt för gamla processmallar. Prova att köra guiden Konfigurera funktioner i varje projekt. Du kan också köra följande witadmin kommando:

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

TF402571: Det nödvändiga elementet BugWorkItems saknas i processkonfigurationen.

Det här felet inträffar vanligtvis när en process inte har uppdaterats på ett tag. Prova att köra guiden Konfigurera funktioner i varje projekt för att lösa problemet.

TF402564: Du har definierat globala XX-listor. Endast 64 tillåts.

Som standard stöder Azure DevOps Services 64 globala listor. Du stöter vanligtvis på det här felet om du har en stor mängd byggpipelines. Den globala listan med namnet Builds – TeamProjectName skapas för varje ny bygg-pipeline. Du måste ta bort de inaktuella globala listorna.