Convalidare e risolvere gli errori correlati ai modelli di processo

  • Articolo

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

Nell'ambito del processo di importazione della migrazione, lo strumento di migrazione dei dati controlla il processo usato dai progetti nella raccolta. Consente di correggere eventuali errori contrassegnati.

Dopo aver risolto gli errori, eseguire di nuovo il comando dello strumento di validate migrazione dei dati per verificare che tutti gli errori siano stati corretti.

Nota

È consigliabile usare la Guida alla migrazione per eseguire l'importazione. La guida è collegata alla documentazione tecnica in base alle esigenze.

Con il rilascio di Azure DevOps Server 2019, il servizio di importazione del database TFS è stato rinominato per eseguire la migrazione ad Azure DevOps. Tra cui TfsMigrator diventa lo strumento di migrazione dei dati o la migrazione per breve tempo. Questo servizio funziona ancora esattamente come il vecchio servizio di importazione. Se si usa una versione precedente di in locale con TFS come personalizzazione è comunque possibile usare questa funzionalità per eseguire la migrazione ad Azure DevOps, purché si eseggi a una delle versioni supportate.

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 CMMI e non è mai stato personalizzato.
  • Modello di processo XML ospitato: se il processo di progetto sembra essere stato 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à. Si noti che una volta importata una raccolta, è possibile eseguire la migrazione di un progetto a un modello di processo di ereditarietà.

La maggior parte dei clienti ha una combinazione di progetti all'interno di una raccolta. Alcuni progetti usano un modello di processo predefinito e altri usano modelli di processo personalizzati. Lo strumento di migrazione dei dati controlla e convalida di conseguenza ogni progetto. È molto possibile che si disponga di una combinazione di progetti, alcuni mappati a un processo ereditato e altri a un processo XML ospitato.

Per qualsiasi progetto che non è stato personalizzato, è consigliabile esaminare il TryMatchOobProcesses.log per determinare se sono presenti errori. In tal caso, apportare le modifiche di conseguenza in modo che il progetto possa essere mappato a un processo ereditato al momento dell'importazione dei dati.

Eseguire l'aggiornamento a un processo di sistema

Se è stata avviata una versione precedente di Azure DevOps Server, le probabilità sono che i progetti usano ancora un modello di processo meno recente. Se tali progetti non sono stati aggiornati tramite la Configurazione guidata funzionalità, lo strumento di migrazione dei dati troverà errori di processo. In alcuni casi rari, se il processo è molto vecchio, anche la Configurazione guidata funzionalità non sarà in grado di risolvere gli errori.

Ecco alcuni esempi di messaggi di errore che è possibile ricevere:

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 è mai stato personalizzato (sono stati aggiunti campi, tipi di elementi di lavoro e così via), la correzione di questi errori è effettivamente piuttosto semplice. Se il processo è stato personalizzato, questo approccio non funzionerà. Sarà necessario modificare manualmente i modelli di processo in modo che le personalizzazioni non vengano sovrascritte.

Prima di tutto, assicurarsi di conoscere il processo avviato dal progetto. È Scrum, Agile o CMMI? In questo esempio si supponga agile. Passare quindi a Process Customization Scripts (Script di personalizzazione dei processi) forniti in GitHub e scaricare il repository. In questo caso, ci concentreremo sul contenuto nella cartella Importa .

Usare lo script ConformProject.ps1 per conformarsi a un progetto scelto per il processo di sistema Agile. In questo modo l'intero progetto verrà aggiornato in modo che sia Agile.

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

Assicurarsi di eseguire questa operazione per ogni progetto e per ogni progetto.

Risolvere errori di processo

I modelli di processo sono personalizzati? Si usa un modello di processo obsoleto meno recente? In questo caso, è probabile che si verifichino errori di convalida del processo. Lo strumento di migrazione dei dati esegue un controllo completo sui modelli di processo. Verifica che sia valido per Azure DevOps Services. Le probabilità sono che dovrai apportare alcune modifiche e applicarle alla raccolta.

Nota

Se si usa un processo OOB Agile, Scrum o CMMI, è probabile che non vengano visualizzati errori nel DataMigrationTool.log. Controllare invece la presenza di errori nel TryMatchOobProcesses.log . Se si è liberi errori, il progetto verrà mappato a un processo OOB.

Esistono diverse personalizzazioni che non funzioneranno in Azure DevOps Services. Assicurarsi di esaminare l'elenco delle personalizzazioni supportate.

Se si dispone di progetti che usano un modello di processo meno recente, lo strumento di migrazione dei dati troverà diversi errori. Ciò è dovuto al fatto che i modelli di processo non sono stati aggiornati in modo che corrispondano ai modelli di processo più recenti. Per iniziare, provare a eseguire la Configurazione guidata funzionalità per ogni progetto. In questo modo si tenterà di aggiornare i modelli di processo con le funzionalità più recenti. In questo modo è consigliabile ridurre drasticamente il numero di errori.

Infine, assicurarsi di avere witadmin nel computer che si intende usare per correggere gli errori del processo. Può trattarsi del desktop locale. Lo witadmin strumento da riga di comando viene usato negli script automatizzati ed è necessario ogni volta che si apportano modifiche ai modelli di processo.

Passaggio 1- Esaminare gli errori

DataMigrationTool.log file verrà generato e contiene l'elenco degli errori rilevati dal processo di convalida. Per visualizzare i log, aprire DataMigrationTool.log file. Cercare la stringa "Convalida - Avvio della convalida del progetto 1". Ogni progetto viene convalidato. Analizza tutti i progetti e cerca tutte le righe contenenti un prefisso [ Errore ....

File di registrazione dei processi generato dallo strumento di migrazione dei dati

Per un elenco degli errori di convalida, vedere Risolvere gli errori di convalida per l'importazione del processo. Per ogni errore di convalida, è stato specificato il numero di errore, la descrizione e il metodo da risolvere.

Passaggio 2 - Correggere gli errori

Dopo aver determinato i progetti con errori e i dettagli dell'errore, correggere gli errori. Per correggere gli errori è necessario modificare la sintassi XML e applicare di nuovo le modifiche al progetto.

Nota

Per eseguire questa operazione, è consigliabile non usare TFS Power Tools. È invece consigliabile modificare manualmente il codice XML.

Per ottenere il modello di processo dal progetto, aggiungere il parametro /SaveProcesses durante l'esecuzione del comando strumento di migrazione dei 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 DataMigrationTool.log file per determinare gli errori per ogni progetto.

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 witadmin changefield comando e quindi eseguire nuovamente lo strumento di migrazione dei dati. In questo modo verrà nuovamente esportato il codice XML con i nomi corretti. In caso contrario, sarà necessario correggere manualmente anche i campi nella sintassi XML.

Dopo aver apportato una correzione, applicare di nuovo le modifiche al server Azure DevOps. A tale scopo, a seconda delle modifiche apportate, è necessario eseguire uno o più witadmin comandi. Per semplificare questa operazione, è stato creato uno script di PowerShell per automatizzare il processo. Lo script contiene tutti i witadmin comandi necessari per conformarsi all'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>"

Script dei processi di progetto conformi in esecuzione

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

Suggerimento

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

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 identity debba avere l'attributo syncnamechanges=true . In Azure DevOps Server tale regola non si applica. Di conseguenza, lo strumento di migrazione dei dati identificherà questo problema. Non preoccuparti, apportare questa modifica in Azure DevOps Server in locale non causerà alcun danno.

Eseguire il comando witadmin changefield. La sintassi per il comando è simile alla seguente:

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

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

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

Questo errore è tipico per i modelli di processo precedenti. Provare a eseguire la Configurazione guidata funzionalità in ogni progetto. In alternativa, è possibile eseguire il comando seguente witadmin :

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

TF402571: Elemento obbligatorio BugWorkItems mancante in Configurazione processo.

Questo errore si verifica in genere quando un processo non è stato aggiornato in un certo periodo di tempo. Provare a eseguire la configurazione guidata delle funzionalità in ogni progetto da risolvere.

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

Per impostazione predefinita, Azure DevOps Services supporterà 64 elenchi globali. In genere si eseguirà questo errore se si dispone di una grande quantità di pipeline di compilazione. L'elenco globale denominato Build - TeamProjectName viene creato per ogni nuova pipeline di compilazione. Sarà necessario rimuovere gli elenchi globali obsoleti.