Überprüfen und Beheben von Fehlern im Zusammenhang mit Prozessvorlagen

  • Artikel

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

Im Rahmen des Migrationsimportprozesses überprüft das Datenmigrationstool den Prozess, der von den Projekten in der Sammlung verwendet wird. Beheben Sie alle Fehler, die gekennzeichnet werden.

Führen Sie nach dem Beheben der Fehler den Befehl des validate Datenmigrationstools erneut aus, um sicherzustellen, dass alle Fehler behoben wurden.

Hinweis

Es wird empfohlen, den Migrationsleitfaden zu verwenden, um den Import zu durchlaufen. Der Leitfaden enthält bei Bedarf Links zur technischen Dokumentation.

Mit der Veröffentlichung von Azure DevOps Server 2019 wurde der TFS-Datenbankimportdienst in Azure DevOps umbenannt. Dazu gehört, dass TfsMigrator zum Datenmigrationstool oder kurz migration wird. Dieser Dienst funktioniert immer noch genau wie der alte Importdienst. Wenn Sie eine ältere lokale Version mit TFS als Branding verwenden, können Sie dieses Feature weiterhin verwenden, um zu Azure DevOps zu migrieren, solange Sie ein Upgrade auf eine der unterstützten Versionen durchführen.

Prozessüberprüfungstypen

Während der Überprüfung bestimmt das Datenmigrationstool das Zielprozessmodell für jedes Projekt. Es weist jedem Projekt in der Auflistung automatisch eines der folgenden beiden Prozessmodelle zu:

  • Geerbtes Prozessmodell: Wenn das Projekt mit der Prozessvorlage Agile, Scrum oder CMMI erstellt wurde und nie angepasst wurde.
  • Gehostetes XML-Prozessmodell: Wenn der Projektprozess anscheinend angepasst wurde. Ein angepasster Prozess enthält benutzerdefinierte Felder, Arbeitsaufgabentypen oder andere Arten von Anpassungen.

Wenn der gehostete XML-Prozess das Zielprozessmodell ist, überprüft das Datenmigrationstool, ob die Anpassungen migriert werden können. Das Datenmigrationstool generiert während der Überprüfung zwei Dateien:

  • DataMigrationTool.log: Enthält den Satz von Prozessüberprüfungsfehlern, die in der Auflistung gefunden wurden. Beheben Sie alle Prozessfehler, die gefunden wurden, um mit der Migration fortzufahren.

  • TryMatchOobProcesses.log: Listet für jedes Projekt das Zielprozessmodell auf – Vererbung oder gehostetes XML. Für Projekte, die auf das Gehostete XML-Prozessmodell festgelegt sind, wird erläutert, warum sie als angepasst betrachtet werden. Sie müssen diese Fehler nicht beheben, aber sie bieten Ihnen Anleitungen, was sie tun müssen, falls Sie zum Vererbungsprozessmodell migrieren möchten. Beachten Sie, dass Sie nach dem Importieren einer Auflistung ein Projekt zu einem Vererbungsprozessmodell migrieren können.

Die meisten Kunden haben eine Mischung aus Projekten in einer Sammlung. Einige Projekte verwenden eine Standardprozessvorlage und andere verwenden benutzerdefinierte Prozessvorlagen. Das Datenmigrationstool überprüft und überprüft jedes Projekt entsprechend. Es ist sehr möglich, dass Sie eine Mischung aus Projekten haben, einige einem geerbten Prozess und anderen einem gehosteten XML-Prozess zugeordnet sind.

Es wird empfohlen, für jedes Projekt, das nicht angepasst wurde, die TryMatchOobProcesses.log zu überprüfen, um festzustellen, ob Fehler vorliegen. Wenn ja, nehmen Sie die Anpassungen entsprechend vor, damit das Projekt beim Datenimport einem geerbten Prozess zugeordnet werden kann.

Aktualisieren auf einen Systemprozess

Wenn Sie mit einer älteren Version von Azure DevOps Server begonnen haben, verwenden Ihre Projekte weiterhin eine ältere Prozessvorlage. Wenn diese Projekte nicht mithilfe des Assistenten zum Konfigurieren von Features aktualisiert wurden, findet das Datenmigrationstool Prozessfehler. Wenn Ihr Prozess sehr alt ist, können in einigen seltenen Fällen auch der Assistent zum Konfigurieren von Features die Fehler nicht beheben.

Hier sind einige Beispiele für Fehlermeldungen, die Sie möglicherweise erhalten:

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.

Wenn Sie Ihr Projekt noch nie angepasst haben (hinzugefügte Felder, Arbeitsaufgabentypen usw.), ist das Beheben dieser Fehler eigentlich ziemlich einfach. Wenn Sie Ihren Prozess angepasst haben, funktioniert dieser Ansatz nicht. Sie müssen die Prozessvorlagen manuell ändern, damit Ihre Anpassungen nicht überschrieben werden.

Stellen Sie zunächst sicher, dass Sie wissen, wie das Projekt gestartet wurde. Ist es Scrum, Agile oder CMMI? In diesem Beispiel gehen wir von Agile aus. Wechseln Sie als Nächstes zu den auf GitHub bereitgestellten Prozessanpassungsskripts , und laden Sie das Repository herunter. In diesem Fall konzentrieren wir uns auf Inhalte im Importordner .

Verwenden Sie das Skript ConformProject.ps1 , um ein Projekt Ihrer Wahl an den Agile-Systemprozess anzupassen. Dadurch wird das gesamte Projekt auf Agile aktualisiert.

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

Stellen Sie sicher, dass Sie dies für jedes Projekt ausführen.

Beheben von Prozessfehlern

Sind Ihre Prozessvorlagen angepasst? Verwenden Sie eine ältere veraltete Prozessvorlage? Wenn ja, haben Sie wahrscheinlich Prozessvalidierungsfehler. Das Datenmigrationstool überprüft vollständig ihre Prozessvorlagen. Es überprüft, ob es für Azure DevOps Services gültig ist. Quoten sind, dass Sie einige Anpassungen vornehmen und auf Ihre Sammlung anwenden müssen.

Hinweis

Wenn Sie einen OOB Agile-, Scrum- oder CMMI-Prozess verwenden, werden wahrscheinlich keine Fehler im DataMigrationTool.log angezeigt. Überprüfen Sie stattdessen die TryMatchOobProcesses.log auf Fehler. Wenn Sie fehlerfrei sind, wird Ihr Projekt einem OOB-Prozess zugeordnet.

Es gibt mehrere Anpassungen, die in Azure DevOps Services nicht funktionieren. Überprüfen Sie die Liste der unterstützten Anpassungen .

Wenn Sie Projekte haben, die eine ältere Prozessvorlage verwenden, wird das Datenmigrationstool mehrere Fehler finden. Dies liegt daran, dass Ihre Prozessvorlagen nicht aktualisiert wurden, um den neuesten Prozessvorlagen zu entsprechen. Führen Sie zunächst den Assistenten zum Konfigurieren von Features für jedes Projekt aus. Dadurch wird versucht, Ihre Prozessvorlagen mit den neuesten Features zu aktualisieren. Dadurch sollte die Fehleranzahl drastisch reduziert werden.

Stellen Sie abschließend sicher, dass Sie auf dem Computer installiert sind witadmin , den Sie verwenden möchten, um die Prozessfehler zu beheben. Dies kann Ihr lokaler Desktop sein. Das witadmin Befehlszeilentool wird in den automatisierten Skripts verwendet und ist erforderlich, wenn Änderungen an den Prozessvorlagen vorgenommen werden.

Schritt 1 : Überprüfen von Fehlern

DataMigrationTool.log Datei wird generiert und enthält die Liste der Fehler, die der Überprüfungsprozess gefunden hat. Um die Protokolle anzuzeigen, öffnen Sie DataMigrationTool.log Datei. Suchen Sie nach der Zeichenfolge "Validation - Starting validation of project 1". Jedes Projekt wird überprüft. Durchsuchen Sie alle Projekte, und suchen Sie nach Zeilen, die ein Präfix von [Fehler ... enthalten.

Prozessprotokollierungsdatei, die vom Datenmigrationstool generiert wird

Eine Liste der Überprüfungsfehler finden Sie unter Beheben von Überprüfungsfehlern für den Prozessimport. Für jeden Überprüfungsfehler haben wir die Fehlernummer, Beschreibung und die Methode bereitgestellt, die behoben werden soll.

Schritt 2 : Beheben von Fehlern

Nachdem Sie festgestellt haben, welche Projekte Fehler haben und welche Fehlerdetails vorliegen, beheben Sie die Fehler. Zum Beheben der Fehler müssen Sie die XML-Syntax ändern und die Änderungen wieder auf das Projekt anwenden.

Hinweis

Es wird empfohlen, diese Arbeit nicht mit TFS Power Tools zu erledigen. Stattdessen wird dringend empfohlen, den XML-Code manuell zu ändern.

Um die Prozessvorlage aus dem Projekt abzurufen, fügen Sie den Parameter "/SaveProcesses " hinzu, wenn Sie den Befehl "Datenmigrationstool" ausführen.

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

Mit diesem Befehl wird der XML-Code aus dem Projekt extrahiert und in denselben Ordner wie die Protokolle eingefügt. Extrahieren Sie die ZIP-Dateien auf Ihren lokalen Computer, damit Sie die Dateien bearbeiten können.

Beheben Sie nun den XML-Code. Verwenden Sie die Protokolle aus der DataMigrationTool.log Datei, um die Fehler für jedes Projekt zu ermitteln.

Prozessprotokollierungsdatei, die vom Datenmigrationstool generiert wird

Bei einigen Fehlern müssen Sie einen witadmin changefield Befehl verwenden. Das Ändern eines Feldnamens ist das häufigste Beispiel. Um sich etwas Zeit zu sparen, empfehlen wir, den witadmin changefield Befehl auszuführen und dann das Datenmigrationstool erneut auszuführen. Dadurch wird der XML-Code mit den korrigierten Namen erneut exportiert. Andernfalls müssen Sie die Felder in der XML-Syntax manuell korrigieren.

Nachdem Sie einen Fix vorgenommen haben, wenden Sie die Änderungen wieder auf den Azure DevOps Server an. Dazu müssen Sie abhängig von den von Ihnen vorgenommenen Änderungen einen oder witadmin mehrere Befehle ausführen. Um dies für Sie zu vereinfachen, haben wir ein PowerShell-Skript erstellt, um den Prozess zu automatisieren. Das Skript enthält alle Befehle, die witadmin erforderlich sind, um den gesamten Prozess zu erfüllen.

Sie können die Skripts unter Prozessanpassungsskripts abrufen. Verwenden Sie das Skript import/ConformProject.ps1 .

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

Ausführen eines Skripts für die Einhaltung von Projektprozessen

Wenn das Skript abgeschlossen ist, führen Sie das Datenmigrationstool erneut aus, um die Sammlung zu überprüfen. Führen Sie die Schritte 1 bis 3 aus, bis das Datenmigrationstool keine weiteren Überprüfungsfehler generiert.

Tipp

Wenn Sie mit XML noch nicht kompatibel sind, witadminempfehlen wir Ihnen, jeweils einen Fix vorzunehmen und dann konform zu sein. Fahren Sie mit dieser Schleife fort, bis alle Fehler behoben werden.

Häufige Überprüfungsfehler

VS402841: Feld X im Arbeitsaufgabentyp "Fehler" hat "syncnamechanges=false", hat jedoch Regeln, die es zu einem Identitätsfeld machen. Identitätsfelder müssen "syncnamechanges=true" haben. Aktualisieren Sie Ihre Prozessvorlage, um diese Änderung einzuschließen.

In Azure DevOps Services haben wir eine Regel hinzugefügt, sodass jedes Identitätsfeld das attribut "syncnamechanges=true " aufweisen muss. In Azure DevOps Server gilt diese Regel nicht. Daher wird das Datenmigrationstool dies als Problem identifizieren. Machen Sie sich keine Sorgen, wenn Sie diese Änderung lokal auf Azure DevOps Server vornehmen, wird kein Schaden verursacht.

Führen Sie den Befehl witadmin changefield aus. Die Syntax für den Befehl sieht ähnlich wie folgt aus:

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

Weitere Informationen zum witadmin changefield Befehl finden Sie unter "Arbeitsaufgabenfelder verwalten".

TF402556: Damit das Feld "System.IterationId" gut definiert ist, müssen Sie die Iterations-ID benennen und den Typ auf "Integer" festlegen.

Dieser Fehler ist typisch für alte Prozessvorlagen. Versuchen Sie, den Assistenten zum Konfigurieren von Features für jedes Projekt auszuführen. Alternativ können Sie den folgenden witadmin Befehl ausführen:

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

TF402571: Das erforderliche Element BugWorkItems fehlt in der Prozesskonfiguration.

Dieser Fehler tritt in der Regel auf, wenn ein Prozess in einer Weile nicht aktualisiert wurde. Versuchen Sie, den Assistenten zum Konfigurieren von Features für jedes Projekt auszuführen, um die Lösung zu beheben.

TF402564: Sie haben globale XX-Listen definiert. Es sind nur 64 zulässig.

Standardmäßig unterstützt Azure DevOps Services 64 globale Listen. Dieser Fehler wird in der Regel ausgeführt, wenn sie über eine große Anzahl von Buildpipelines verfügen. Die globale Liste mit dem Namen Builds – TeamProjectName wird für jede neue Buildpipeline erstellt. Sie müssen die veralteten globalen Listen entfernen.