Condividi tramite

Convalidare e preparare l'ambiente server per la migrazione

  • Articolo

La convalida prevede la preparazione dell'ambiente azure DevOps Server aggiornato per la migrazione. Questo articolo illustra come risolvere i problemi comuni. Se non sono stati rilevati errori e tutti i controlli di convalida superati, la raccolta di progetti team è pronta ed è possibile passare alla fase successiva. Esaminare i file di log per individuare eventuali errori se non tutti i controlli superati.

Diagramma della fase convalida evidenziata delle sette fasi della migrazione.

Prerequisiti

Scaricare l'ultimo strumento di migrazione dei dati.

Informazioni sui tipi di convalida dei processi

Durante la convalida, lo strumento di migrazione dei dati determina il modello di processo di destinazione per ogni progetto. Assegna automaticamente uno dei due modelli di processo seguenti a ogni progetto nella raccolta:

  • Modello di processo ereditato: se il progetto è stato creato con il modello di processo Agile, Scrum o Capability Maturity Model Integration (CMMI) e non è mai stato personalizzato.
  • Modello di processo XML ospitato: se il processo di progetto sembra essere personalizzato. Un processo personalizzato contiene campi personalizzati, tipi di elementi di lavoro o altri tipi di personalizzazioni.

Quando il processo XML ospitato è il modello di processo di destinazione, lo strumento di migrazione dei dati convalida se è possibile eseguire la migrazione delle personalizzazioni. Lo strumento di migrazione dei dati genera due file durante la convalida:

  • DataMigrationTool.log: contiene il set di errori di convalida del processo trovati nella raccolta. Correggere tutti gli errori di processo rilevati per procedere con la migrazione.
  • TryMatchOobProcesses.log: elenca per ogni progetto il modello di processo di destinazione - Ereditarietà o XML ospitato. Per i progetti impostati come destinazione del modello di processo XML ospitato, spiega perché vengono considerati personalizzati. Non è necessario correggere questi errori, ma forniscono indicazioni su cosa fare nel caso in cui si voglia eseguire la migrazione al modello di processo di ereditarietà. Dopo aver eseguito la migrazione di una raccolta, è possibile eseguire la migrazione di un progetto a un modello di processo di ereditarietà.

Convalidare una raccolta di progetti team

Poiché ogni raccolta di progetti team corrisponde al proprio database SQL, il processo di convalida esamina vari aspetti della raccolta, tra cui:

  • Dimensioni del database di raccolta
  • Regole di confronto del database SQL
  • Identità degli utenti nella raccolta
  • Personalizzazioni dei modelli (processo)

Per avviare la convalida, usare lo strumento di migrazione. È consigliabile eseguire lo strumento di migrazione da uno dei server del livello applicazione (AT) nell'ambiente Azure DevOps Server.

Per opzioni della riga di comando specifiche, richiedere il testo della Guida usando il comando seguente:

	Migrator validate /help

Il modo più comune per avviare la convalida consiste nel specificare l'URL della raccolta di progetti team con la struttura seguente:

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

Visualizzare avvisi ed errori di convalida

Al termine dello strumento di migrazione, genera i file di log e i risultati visualizzati nella schermata del prompt dei comandi. Se non si verificano errori e vengono superati tutti i controlli di convalida, la raccolta di progetti team è pronta per la fase successiva. In caso di esito negativo dei controlli di convalida, esaminare i file di log per identificare gli errori e quindi risolverli.

Concentrarsi sul Migrator.log file, che contiene dettagli essenziali sui controlli di convalida e consente di mantenere la personalizzazione. Gli altri file corrispondono a errori di convalida specifici in base ai relativi nomi. Cercare la stringa "Convalida - Avvio della convalida del progetto 1". Ogni progetto viene convalidato. Analizzare tutti i progetti e cercare tutte le righe contenenti un prefisso di [Error...

TryMatchOobProcesses.log Vengono inoltre elencati gli errori correlati ai progetti che usano processi OOB (Out-of-Box), ad esempio Agile, Scrum o CMMI. Se un progetto usa un processo OOB senza personalizzazioni, il progetto viene incluso nel modello ereditato. In particolare, gli errori in questo file non ostacolano il processo di migrazione.

Screenshot del file DataMigrationTool.log generato dallo strumento di migrazione dei dati.

Per un elenco degli errori di convalida, vedere Risolvere gli errori di convalida. Per ogni errore di convalida è stato specificato il numero di errore, la descrizione e il metodo da risolvere. Nei log dei controlli di convalida potrebbero essere visualizzati vari tipi di errore. Richiedere assistenza al partner DevOps, ai Servizi di consulenza Microsoft o al supporto Tecnico Microsoft Premier per la risoluzione degli errori riscontrati.

Risolvere gli errori del modello di processo

Gli errori principali riscontrati sono problemi relativi al modello di processo. Questi problemi derivano da progetti team obsoleti che non incorporano le funzionalità più recenti di Azure DevOps Server o le personalizzazioni non supportate da Azure DevOps Services. Azure DevOps Services supporta tuttavia una serie di personalizzazioni e la convalida contrassegna solo quelli che richiedono premi di risoluzione. Lo strumento di migrazione dei dati esegue un controllo completo dei modelli per la compatibilità di Azure DevOps Services, ma potrebbero essere necessarie alcune modifiche.

  • I modelli di processo personalizzati o i modelli obsoleti possono causare errori di convalida dei processi durante la migrazione.
  • Se si usa un processo OOB Agile, Scrum o CMMI, verificare la presenza di TryMatchOobProcesses.log errori. I progetti senza errori eseguono il mapping ai processi OOB.
  • Alcune personalizzazioni non funzionano in Azure DevOps Services. Esaminare l'elenco di personalizzazione supportato.
  • Per i progetti che usano modelli meno recenti, eseguire la Configurazione guidata funzionalità per aggiornare i modelli con funzionalità recenti e ridurre il numero di errori.
  • Assicurarsi che witadmin sia disponibile nel computer in cui è possibile correggere gli errori del processo. È essenziale apportare modifiche ai modelli di elaborazione.
  • Per e Non le regole devono essere impostate come commento o rimosse dal modello di processo prima di tentare la migrazione. Queste regole sono supportate nel servizio Azure DevOps, ma non sono supportate come parte del processo di migrazione. Dopo aver eseguito la migrazione della raccolta, è possibile aggiungere di nuovo queste regole al modello di processo.

Prendere in considerazione gli strumenti seguenti per la risoluzione degli errori di processo:

  • Usare lo strumento da riga di comando witadmin.exe incluso nelle installazioni di Visual Studio. La documentazione tecnica dettagliata su come risolvere questi errori è disponibile in questo collegamento.
  • Automatizzare l'esportazione dei modelli di processo per ogni progetto team usando un comando dello strumento di migrazione non documentato: Migrat convalida /collection:http://localhost:8080/tfs/DefaultCollection /SaveProcesses.
  • Esplorare TFS Team Project Manager in GitHub (collegamento). Consente di confrontare i progetti team con modelli di processo noti, inclusi i modelli predefiniti.

Per correggere gli errori, modificare la sintassi XML e applicare di nuovo le modifiche al progetto.

Suggerimento

È consigliabile modificare manualmente il codice XML anziché usare TFS Power Tools.

Per ottenere il modello di processo dal progetto, aggiungere il /SaveProcesses parametro quando si esegue il comando Strumento di migrazione dati.

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

Questo comando estrae il codice XML dal progetto e lo inserisce nella stessa cartella dei log. Estrarre i file ZIP nel computer locale in modo da poter modificare i file.

Correggere ora il codice XML. Usare i log del file di DataMigrationTool.log per determinare gli errori per ogni progetto.

Screenshot del file di registrazione dei processi generato dallo strumento di migrazione dei dati.

Alcuni errori richiedono l'uso di un witadmin changefield comando. La modifica di un nome di campo è l'esempio più comune. Per risparmiare tempo, è consigliabile eseguire il comando witadmin changefield e quindi eseguire di nuovo lo Strumento di migrazione dei dati. In questo modo, il codice XML viene nuovamente esportato con i nomi corretti. In caso contrario, correggere manualmente anche i campi nella sintassi XML.

Dopo aver apportato una correzione, applicare di nuovo le modifiche al server Azure DevOps. A seconda delle modifiche apportate, è necessario eseguire uno o più comandi witadmin. È stato creato uno script di PowerShell per automatizzare questo processo. Lo script contiene tutti i comandi witadmin necessari per confermare l'intero processo.

È possibile ottenere gli script in Script di personalizzazione dei processi. Usare lo script import/ConformProject.ps1.

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

Al termine dello script, eseguire di nuovo lo strumento di migrazione dei dati per convalidare la raccolta. Seguire i passaggi da 1 a 3 fino a quando lo strumento di migrazione dei dati non genera altri errori di convalida.

Screenshot del processo di progetto conforme in PowerShell.

Suggerimento

Se non si ha familiarità con XML e witadmin, è consigliabile apportare una correzione alla volta e quindi conformarsi. Continuare questo ciclo fino a quando non vengono risolti tutti gli errori.

Eseguire l'aggiornamento a un processo di sistema

Se si è iniziato con una versione precedente di Azure DevOps Server, è probabile che i progetti usino un modello di processo meno recente. Se questi progetti non sono stati aggiornati tramite la Configurazione guidata funzionalità, lo strumento di migrazione dei dati rileva errori di processo. In rari casi, anche la procedura guidata potrebbe non risolvere i problemi relativi ai processi precedenti.

È possibile che vengano visualizzati alcuni dei seguenti messaggi di errore di esempio:

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.

Se il progetto non è stato personalizzato( ad esempio, sono stati aggiunti campi, tipi di elemento di lavoro e così via), la correzione di questi errori è semplice. Tuttavia, se il processo è stato personalizzato, questo approccio non è sufficiente. È necessario modificare manualmente i modelli di processo per mantenere le personalizzazioni da sovrascrivere.

Eseguire i passaggi seguenti per ogni progetto per allineare il processo:

  1. Identificare il processo iniziale del progetto avviato con (Scrum, Agile o CMMI).
  2. Visitare gli script di personalizzazione dei processi in GitHub e scaricare il repository.
  3. Concentrarsi sul contenuto nella cartella Migrazione.
  4. Usare lo script seguente ConformProject.ps1 per allineare un progetto di propria scelta al processo di sistema Agile. Questa azione aggiorna l'intero progetto in modo che sia Agile.
.\ConformProject.ps1 "<collection url>" "<project name>" "c:\process-customization-scripts\import\agile"

Errori di convalida comuni

VS402841: il campo X nel tipo di elemento di lavoro Bug ha syncnamechanges=false, ma ha regole che lo rendono un campo Identity. I campi Identity devono avere syncnamechanges=true. Aggiornare il modello di processo per includere questa modifica.

In Azure DevOps Services è stata aggiunta una regola in modo che ogni campo di identità debba avere l'attributo syncnamechanges=true . In Azure DevOps Server tale regola non si applica. Di conseguenza, lo strumento di migrazione dei dati identifica questo problema come problema. L'esecuzione di questa modifica in Azure DevOps Server in locale non causa danni.

Eseguire il comando witadmin changefield . La sintassi per il comando è simile all'esempio seguente.

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

Per altre informazioni sul comando witadmin changefield , vedere Gestire i campi dell'elemento di lavoro.

TF402556: per definire correttamente il campo System.IterationId, è necessario denominarlo ID iterazione e impostarne il tipo su Integer.

Questo errore è spesso associato a modelli di processo obsoleti. Per risolverlo, è possibile eseguire la Configurazione guidata funzionalità per ogni progetto. In alternativa, è possibile eseguire il comando seguente per automatizzare il processo.

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

TF402571: Elemento obbligatorio BugWorkItems mancante in Configurazione processo.

Questo errore viene comunemente rilevato quando un processo non è stato aggiornato per un certo periodo di tempo. Per correggerlo, eseguire la Configurazione guidata funzionalità per ogni progetto.

TF402564: sono stati definiti elenchi globali XX. Sono consentiti solo 64

Azure DevOps Services supporta in modo nativo 64 elenchi globali. Questo errore si verifica in genere quando è presente un numero elevato di pipeline di compilazione, poiché ogni nuova pipeline crea un elenco globale denominato Builds - TeamProjectName. Per risolvere questo errore, rimuovere eventuali elenchi globali obsoleti.

Ripetere i controlli di convalida

In ogni iterazione, risolvere gli errori e condurre controlli di convalida per risolverli, come indicato dai file di log di convalida. Persistenza con questo ciclo fino a quando non vengono rettificati tutti gli errori e si riceve la conferma che i controlli di convalida della raccolta hanno esito positivo.

Passaggi successivi

Preparare l'esecuzione dei test