Freigeben über

Überprüfen und Vorbereiten der Serverumgebung für die Migration

  • Artikel

Die Überprüfung umfasst die Vorbereitung Ihrer aktualisierten Azure DevOps Server-Umgebung für die Migration. Dieser Artikel unterstützt Sie bei der Problembehandlung häufig auftretender Probleme. Wenn keine Fehler aufgetreten sind und alle Validierungsprüfungen bestanden wurden, ist Ihre Teamprojektsammlung bereit, und Sie können zur nächsten Phase fortfahren. Durchsuchen Sie die Protokolldateien, um Fehler zu finden, wenn nicht alle Prüfungen bestanden wurden.

Diagramm der hervorgehobenen Überprüfungsphase der sieben Phasen der Migration.

Voraussetzungen

Laden Sie das neueste Datenmigrationstool herunter.

Weitere Informationen zu 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 Capability Maturity Model Integration (CMMI) erstellt wurde und nie angepasst wurde.
  • Gehostetes XML-Prozessmodell: Wenn der Projektprozess anscheinend angepasst wird. 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. Sobald eine Sammlung migriert wird, können Sie ein Projekt zu einem Vererbungsprozessmodell migrieren.

Überprüfen einer Teamprojektsammlung

Da jede Teamprojektsammlung einer eigenen SQL-Datenbank entspricht, untersucht der Überprüfungsprozess verschiedene Aspekte Ihrer Sammlung, darunter:

  • Größe der Sammlungsdatenbank
  • Sortierung der SQL-Datenbank
  • Identitäten von Benutzern in der Sammlung
  • Vorlagenanpassungen (Prozess)

Verwenden Sie das Migrationstool, um die Überprüfung zu starten. Es wird empfohlen, das Migrationstool von einem der AT-Server (Application Tier) in Ihrer Azure DevOps Server-Umgebung auszuführen.

Für bestimmte Befehlszeilenoptionen fordern Sie Hilfetext mithilfe des folgenden Befehls an:

	Migrator validate /help

Die am häufigsten verwendete Methode zum Starten der Überprüfung besteht darin, die URL der Teamprojektsammlung mit der folgenden Struktur anzugeben:

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

Anzeigen von Überprüfungswarnungen und Fehlern

Nach Abschluss des Migrationstools werden Protokolldateien und Ergebnisse generiert, die auf dem Eingabeaufforderungsbildschirm angezeigt werden. Wenn keine Fehler auftreten und alle Validierungsprüfungen bestehen, ist Ihre Teamprojektsammlung für die nächste Phase bereit. Wenn Überprüfungen fehlschlagen, überprüfen Sie die Protokolldateien, um Fehler zu identifizieren, und beheben Sie sie dann.

Konzentrieren Sie sich auf die Migrator.log Datei, die wesentliche Details zu den Überprüfungen enthält, und hilft Ihnen, die Anpassung beizubehalten. Die anderen Dateien entsprechen bestimmten Überprüfungsfehlern basierend auf ihren Namen. Suchen Sie nach der Zeichenfolge "Validierung - Start der Validierung von Projekt 1". Jedes Projekt wird überprüft. Durchsuchen Sie alle Projekte, und suchen Sie nach Zeilen, die ein Präfix von [Error...

Außerdem werden fehler im Zusammenhang mit Projekten aufgelistet, TryMatchOobProcesses.log die Out-of-Box(OOB)-Prozesse (z. B. Agile, Scrum oder CMMI) verwenden. Wenn ein Projekt einen OOB-Prozess ohne Anpassungen verwendet, ist das Projekt im geerbten Modell enthalten. Wichtig ist, dass Fehler in dieser Datei den Migrationsprozess nicht behindern.

Screenshot der vom Datenmigrationstool generierten DataMigrationTool.log Datei.

Eine Liste der Überprüfungsfehler finden Sie unter Beheben von Überprüfungsfehlern. Für jeden Überprüfungsfehler haben wir die Fehlernummer, Beschreibung und die Methode bereitgestellt, die behoben werden soll. In den Überprüfungsprotokollen werden möglicherweise verschiedene Fehlertypen angezeigt. Suchen Sie Unterstützung von Ihrem geschulten DevOps-Partner, Microsoft Consulting Services oder Microsoft Premier Support, um aufgetretene Fehler zu beheben.

Beheben von Prozessvorlagenfehlern

Die wichtigsten Fehler, die wir finden, sind Prozessvorlagenprobleme. Diese Probleme stammen aus veralteten Teamprojekten, die nicht die neuesten Features von Azure DevOps Server oder nicht unterstützte Anpassungen von Azure DevOps Services enthalten. Azure DevOps Services unterstützt jedoch eine Reihe von Anpassungen, und die Überprüfung kennzeichnet nur diejenigen, die eine Auflösungsvormigration erfordern. Das Datenmigrationstool führt eine umfassende Überprüfung Ihrer Vorlagen für die Kompatibilität von Azure DevOps Services durch, einige Änderungen sind jedoch möglicherweise erforderlich.

  • Angepasste Prozessvorlagen oder veraltete Vorlagen können während der Migration zu Prozessüberprüfungsfehlern führen.
  • Wenn Sie einen OOB Agile-, Scrum- oder CMMI-Prozess verwenden, überprüfen Sie die TryMatchOobProcesses.log Fehler. Fehlerfreie Projekte werden OOB-Prozessen zugeordnet.
  • Einige Anpassungen funktionieren in Azure DevOps Services nicht. Überprüfen Sie die Liste der unterstützten Anpassungen.
  • Führen Sie für Projekte mit älteren Vorlagen den Assistenten zum Konfigurieren von Features aus, um Vorlagen mit den neuesten Features zu aktualisieren und die Fehleranzahl zu verringern.
  • Stellen Sie sicher, dass witadmin auf dem Computer verfügbar ist, auf dem Sie Prozessfehler beheben. Es ist wichtig, Änderungen an Prozessvorlagen vorzunehmen.
  • "For" und "Not"-Regeln sollten vor dem Versuch der Migration auskommentiert oder aus der Prozessvorlage entfernt werden. Diese Regeln werden in Azure DevOps Service unterstützt, werden jedoch nicht als Teil des Migrationsprozesses unterstützt. Nachdem Ihre Sammlung migriert wurde, können Sie diese Regeln wieder zur Prozessvorlage hinzufügen.

Berücksichtigen Sie die folgenden Tools zum Beheben von Prozessfehlern:

  • Verwenden Des witadmin.exe Befehlszeilentools, das in Visual Studio-Installationen enthalten ist. Detaillierte technische Dokumentation zur Behebung dieser Fehler finden Sie unter diesem Link.
  • Automatisieren Sie das Exportieren von Prozessvorlagen für jedes Teamprojekt mithilfe eines Befehls für nicht dokumentierte Migrationstools: Migration überprüft /collection:http://localhost:8080/tfs/DefaultCollection /SaveProcesses.
  • Erkunden Sie den TFS Team Project Manager auf GitHub (Link). Es ermöglicht Ihnen, Teamprojekte mit bekannten Prozessvorlagen zu vergleichen, einschließlich sofort einsatzbereiter Vorlagen.

Um die Fehler zu beheben, ändern Sie die XML-Syntax, und wenden Sie die Änderungen wieder auf das Projekt an.

Tipp

Es wird empfohlen, den XML-Code manuell zu ändern, anstatt TFS Power Tools zu verwenden.

Um die Prozessvorlage aus dem Projekt abzurufen, fügen Sie den /SaveProcesses Parameter 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 datei DataMigrationTool.log, um die Fehler für jedes Projekt zu ermitteln.

Screenshot der 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 Befehl "witadmin changefield " auszuführen und dann das Datenmigrationstool erneut auszuführen. Dadurch wird der XML-Code mit den korrigierten Namen erneut exportiert. Korrigieren Sie andernfalls auch die Felder in der XML-Syntax manuell.

Nachdem Sie einen Fix vorgenommen haben, wenden Sie die Änderungen wieder auf den Azure DevOps Server an. Je nachdem, welche Änderungen Sie vorgenommen haben, müssen Sie einen oder mehrere witadmin-Befehle ausführen. Wir haben ein PowerShell-Skript erstellt, um diesen Prozess zu automatisieren. Das Skript enthält alle witadmin-Befehle, die zum Bestätigen des gesamten Prozesses erforderlich sind.

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

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

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.

Screenshot des konformen Projektprozesses in PowerShell.

Tipp

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

Aktualisieren auf einen Systemprozess

Wenn Sie mit einer älteren Version von Azure DevOps Server begonnen haben, verwenden Ihre Projekte wahrscheinlich eine ältere Prozessvorlage. Wenn diese Projekte nicht mithilfe des Assistenten zum Konfigurieren von Features aktualisiert wurden, erkennt das Datenmigrationstool Prozessfehler. In seltenen Fällen kann auch der Assistent alte prozessbezogene Probleme nicht beheben.

Möglicherweise erhalten Sie einige der folgenden Beispielfehlermeldungen:

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 nicht angepasst haben (z. B. hinzugefügte Felder, Arbeitsaufgabentypen usw.), ist das Beheben dieser Fehler einfach. Aber wenn Sie Ihren Prozess angepasst haben, reicht dieser Ansatz nicht aus. Sie müssen die Prozessvorlagen manuell anpassen, damit Ihre Anpassungen nicht überschrieben werden.

Führen Sie die folgenden Schritte für jedes Projekt aus, um den Prozess auszurichten:

  1. Identifizieren Sie den anfänglichen Prozess, mit dem Ihr Projekt begonnen hat (Scrum, Agile oder CMMI).
  2. Besuchen Sie die Prozessanpassungsskripts auf GitHub, und laden Sie das Repository herunter.
  3. Konzentrieren Sie sich auf den Inhalt im Migrationsordner.
  4. Verwenden Sie das folgende ConformProject.ps1 Skript, um ein Projekt Ihrer Wahl mit dem Agile-Systemprozess auszurichten. Diese Aktion aktualisiert das gesamte Projekt auf Agile.
.\ConformProject.ps1 "<collection url>" "<project name>" "c:\process-customization-scripts\import\agile"

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 syncnamechanges=true Attribut aufweisen muss. In Azure DevOps Server gilt diese Regel nicht. Daher identifiziert das Datenmigrationstool dies als Problem. Wenn Sie diese Änderung lokal auf Azure DevOps Server vornehmen, wird kein Schaden verursacht.

Führen Sie den Befehl "witadmin" aus changefield . Die Syntax für den Befehl sieht wie im folgenden Beispiel aus.

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

Weitere Informationen zum Befehl "witadmin changefield " finden Sie unter "Verwalten von Arbeitsaufgabenfeldern".

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 häufig veralteten Prozessvorlagen zugeordnet. Um dies zu beheben, können Sie den Assistenten zum Konfigurieren von Features für jedes Projekt ausführen. Alternativ können Sie den folgenden Befehl ausführen, um den Prozess zu automatisieren.

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

TF402571: Das erforderliche Element BugWorkItems fehlt in der Prozesskonfiguration.

Dieser Fehler wird häufig angezeigt, wenn ein Prozess seit einiger Zeit nicht aktualisiert wurde. Führen Sie zum Beheben des Features-Assistenten für jedes Projekt den Assistenten zum Konfigurieren von Features aus.

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

Azure DevOps Services unterstützt 64 globale Listen nativ. Dieser Fehler tritt in der Regel auf, wenn eine umfangreiche Anzahl von Buildpipelines vorhanden ist, da jede neue Pipeline eine globale Liste mit dem Namen Builds - TeamProjectNameerstellt. Um diesen Fehler zu beheben, entfernen Sie alle veralteten globalen Listen.

Überprüfungen wiederholen

Beheben Sie in jeder Iteration Fehler und führen Sie Überprüfungen durch, um sie zu beheben, wie in den Validierungsprotokolldateien angegeben. Beibehalten mit diesem Zyklus, bis alle Fehler korrigiert werden, und Sie erhalten eine Bestätigung, dass die Überprüfungen der Sammlung erfolgreich sind.

Nächste Schritte

Vorbereiten der Testausführung