Übersicht über die Migration von Azure DevOps zu GitHub Enterprise Cloud

Übersicht

Mit GitHub Enterprise Importer kannst du repositoryweise zu GitHub Enterprise Cloud migrieren. Weitere Informationen finden Sie unter Informationen zu GitHub Enterprise Importer.

Wenn du von Azure DevOps (ADO) migrierst, kannst du diesen Leitfaden verwenden, um deine Migration zu planen und zu implementieren und Folgeaufgaben durchzuführen.

Unternehmen, die von ADO zu GitHub migrieren, verfolgen in der Regel einen mehrstufigen Ansatz.

1. Migrieren von Repositorys von ADO zu GitHub
2. Migrieren von Pipelines von Azure Pipelines zu GitHub Actions
3. Migrieren der verbleibenden Ressourcen (z. B. Boards und Artefakte) von ADO zu GitHub

Dieser Leitfaden führt dich durch den Abschluss der ersten Phase: das Migrieren von Repositorys zu GitHub. Es wird vorausgesetzt, dass du die ADO2GH extension of the GitHub CLI verwendest.

Planen der Migration

Stelle dir die folgenden Fragen, um deine Migration zu planen.

• Wie schnell muss die Migration abgeschlossen werden?
• Weißt du, was migriert wird?
• Wer führt die Migration aus?
• Welche Organisationsstruktur möchtest du in GitHub verwenden?

Wie schnell muss die Migration abgeschlossen werden?

Bestimme den Zeitplan für deinen Ansatz. Als ersten Schritt zum Bestimmen deines Zeitplans machst du eine Bestandsaufnahme der zu migrierenden Elemente.

• Anzahl von Repositorys
• Anzahl der Pull Requests

Wenn du eine Migration von Azure DevOps durchführst, empfehlen wir den inventory-report-Befehl in der ADO2GH extension of the GitHub CLI. Der inventory-report Befehl stellt eine Verbindung mit der Azure DevOps-API her und erstellt eine sehr einfache CSV-Datei mit einigen der oben vorgeschlagenen Felder. Um die ADO2GH extension of the GitHub CLI zu installieren und dich zu authentifizieren, führe die Schritte 1 bis 3 unter Migrieren von Repositorys von Azure DevOps zu GitHub Enterprise Cloud aus.

Der Zeitplan für die Migration hängt weitgehend von der Anzahl der Pull Requests in einem Repository ab. Wenn du 1.000 Repositorys migrieren möchtest und jedes Repository durchschnittlich 100 Pull Requests aufweist und nur 50 Benutzer zu den Repositorys beigetragen haben, wird deine Migration wahrscheinlich sehr schnell erfolgen. Wenn du nur 100 Repositorys migrieren möchtest, aber die Repositorys durchschnittlich 75.000 Pull Requests und 5.000 Benutzer aufweisen, dauert die Migration länger und erfordert mehr Planung und Tests.

Nachdem du eine Bestandsaufnahme der zu migrierenden Repositorys durchgeführt hast, kannst du deine Bestandsdaten anhand der gewünschten Zeitachse gewichten. Wenn deine Organisation eine größere Anzahl von Änderungen verträgt, kannst du möglicherweise auch alle deine Repositorys gleichzeitig migrieren und so deine Migration in wenigen Tagen abschließen. Möglicherweise können jedoch nicht alle Teams gleichzeitig migriert werden. In diesem Fall solltest du die Migration in Batches und gestaffelt nach den Planungen der Teams anpassen und so deine Migration schrittweise ausdehnen.

1. Bestimme, wie viele Repositorys und Pull Requests du migrieren musst.
2. Um zu verstehen, wann die einzelne Teams für die Migration bereit sein können, solltest du mit allen Projektbeteiligten reden.
3. Sieh dir den Rest dieses Leitfadens an, und entscheide dich dann für einen Zeitplan für die Migration.

Weißt du, was migriert wird?

Stelle sicher, dass du und deine Projektbeteiligten verstehen, welche Daten von GitHub Enterprise Importer migriert werden können.

Bei der Migration von ADO migriert GitHub Enterprise Importer nur Git-Repositorys, einschließlich Pull Requests und einige Branchrichtlinien. Alle anderen Ressourcen, wie Pipelines, Arbeitselemente, Artefakte, Testpläne, Releases und Dashboards, verbleiben in ADO.

Da Berechtigungen in GitHub anders funktionieren als in ADO, versucht GitHub Enterprise Importer nicht, Repositoryberechtigungen von ADO zu migrieren. Weitere Informationen findest du unter Konfigurieren von Berechtigungen.

Service Hooks werden nicht von ADO migriert und müssen separat neu erstellt werden.

1. Überprüfe die Daten, die aus Azure DevOps migriert werden. Weitere Informationen finden Sie unter Informationen zu Migrationen von Azure DevOps zu GitHub Enterprise Cloud.
2. Erstelle eine Liste aller Daten, die du manuell migrieren oder neu erstellen musst.

Wer führt die Migration aus?

Um ein Repository zu migrieren, musst du Organisationsbesitzerin für die Zielorganisation sein, oder dir muss von einem/einer Organisationsbesitzerin die Migrationsrolle zugewiesen worden sein.

1. Entscheide, ob eine Organisationsbesitzerin der Zielorganisation deine Migrationsvorgänge durchführen soll oder ob du die Migrationsrolle einer anderen Person zuweisen musst.
2. Wenn du dich für die Rolle „Migrator“ entschieden hast, musst du entscheiden, welcher Person oder welchem Team du die Rolle zuweisen möchtest.
3. Weise der Person oder dem Team die Rolle „Migrator“ zu. Weitere Informationen findest du unter Verwalten des Zugriffs für eine Migration von Azure DevOps.
4. Vergewissere dich, dass die Person die personal access token ordnungsgemäß konfiguriert hat, sodass sie alle Zugriffsanforderungen erfüllen. Weitere Informationen findest du unter Verwalten des Zugriffs für eine Migration von Azure DevOps.

Welche Organisationsstruktur möchtest du in GitHub verwenden?

Plane als Nächstes, welche Organisationsstruktur du in GitHub erstellen möchtest. In ADO und GitHub wird die Arbeit eines Unternehmens unterschiedlich organisiert.

• ADO: Organisation > Teamprojekt > Repositorys
• GitHub: Unternehmen > Organisation > Repositorys

Nach der Migration zu GitHub solltest du nur über ein Unternehmenskonto und eine kleine Anzahl von Organisationen verfügen, die sich im Besitz dieses Unternehmens befinden. Jede Organisation in ADO sollte einer einzelnen Organisation in GitHub entsprechen. Es wird nicht empfohlen, für jedes Teamprojekt in ADO eine Organisation in GitHub zu erstellen.

Dies kann zu einer großen Menge nicht gruppierter Repositorys innerhalb jeder Organisation führen. Du kannst jedoch den Zugriff auf Repositorygruppen verwalten, indem du Teams erstellst. Weitere Informationen finden Sie unter Informationen zu Teams.

Wenn du deine Migration in Batches aufteilen möchtest, kannst du mit der neuen Struktur deine Batches ermitteln. Wenn du in ADO mehrere Organisationen hast und die Repositorys jeder Organisation Batches mit angemessener Größe ergeben, solltest du die Batchverarbeitung nach Organisation in Betracht ziehen. Du kannst die GitHub CLI verwenden, um ein Migrationsskript für eine gesamte Organisation in ADO zu generieren.

1. Entscheide, wie deine neue Organisationsstruktur aussehen soll.
2. Entscheide, ob du den Migrationsaufwand in kleinere Batches aufteilen musst.
3. Bei einer Aufteilung musst du außerdem entscheiden, wie du die Migrationsvorgänge aufteilen möchtest.

Ausführen deiner Migrationen

Nachdem du deine Planung abgeschlossen hast, kannst du die eigentlichen Migrationsvorgänge starten. Um Probleme während oder nach der Migration aufzudecken, die möglicherweise für dein Unternehmen einzigartig sind, wird dringend empfohlen, Testläufe aller Migrationsvorgänge durchzuführen. Nachdem du alle Probleme behoben hast, die bei den Testläufen entdeckt wurden, kannst du die Produktionsmigration ausführen.

Testmigrationsläufe helfen dabei, wichtige Informationen zu sammeln.

• Kann die Migration für ein bestimmtes Repository erfolgreich abgeschlossen werden?
• Kann das Repository wieder in einen Zustand versetzt werden, in dem die Benutzer*innen erfolgreich mit der Arbeit beginnen können?
• Wie lange dauert die Ausführung einer Migration? Dies ist nützlich für die Planung von Migrationszeitplänen und das Festlegen der Erwartungen der Beteiligten.

Testläufe erfordern nicht viel Zeit für die Planung. GitHub Enterprise Importer verursacht nie Ausfallzeiten für Benutzerinnen eines zu migrierenden Repositorys. Es wird jedoch empfohlen, die Arbeit während der Produktionsmigration zu unterbrechen, um sicherzustellen, dass während der Migration keine neuen Daten erstellt werden, die dann im migrierten Repository fehlen würden. Dies stellt bei einer Testmigration kein Problem dar, sodass Testläufe jederzeit stattfinden können. Um die Zeit zu verkürzen, die zum Abschließen deiner Testmigration benötigt wird, kannst du die Batches für die Testläufe so planen, dass sie nacheinander ausgeführt werden. Benutzerinnen dieser Repositorys können die Ergebnisse dann selbst überprüfen.

Es wird empfohlen, eine Testorganisation zu erstellen, die als Ziel für deine Testmigrationsvorgänge verwendet wird. Du kannst eine einzelne Organisation für alle Testläufe verwenden, oder du kannst eine Testorganisation für jede vorgesehene Zielorganisation erstellen. Erwäge, am Ende der Organisationsnamen -sandbox einzufügen, um zu verdeutlichen, dass die Organisationen nur für die Migrationsvalidierung und nicht für die Produktion vorgesehen sind. Du kannst die Testorganisationen löschen, wenn du fertig bist.

1. Erstelle eine Testorganisation für deine Testmigrationsvorgänge.
2. Führe die Testmigrationsvorgänge aus.
3. Führe die unten beschriebenen Nachverfolgungsaufgaben für die Testmigrationsvorgänge aus.
4. Bitte die Benutzer*innen, die Ergebnisse der Migrationsvorgänge zu überprüfen.
5. Behebe alle Probleme, die durch die Testmigrationsvorgänge aufgedeckt wurden.
6. Wenn am Ziel Listen zulässiger IP-Adressen verwendet werden, musst du die Liste so konfigurieren, dass der Zugriff von GitHub Enterprise Importer zugelassen wird. Weitere Informationen findest du unter Verwalten des Zugriffs für eine Migration von Azure DevOps.
7. Führe deine Produktionsmigrationen aus. Weitere Informationen finden Sie unter Migrieren von Repositorys von Azure DevOps zu GitHub Enterprise Cloud.
8. Lösche optional die Testorganisation.

Ausführen von Folgeaufgaben

Nachdem alle Migrationsvorgänge abgeschlossen wurden, musst du einige zusätzliche Aufgaben ausführen, bevor das Repository einsatzbereit ist.

• Überprüfen des Migrationsstatus
• Überprüfen des Migrationsprotokolls
• Sichtbarkeit eines Repositorys festlegen
• Konfigurieren von Berechtigungen
• Freigeben von Mannequins
• Konfigurieren von IP-Zulassungslisten

Überprüfen des Migrationsstatus

Überprüfen Sie zunächst, ob die Migration erfolgreich war oder fehlgeschlagen ist.

Die Art und Weise, wie Sie den Status Ihrer Migration überprüfen, hängt davon ab, wie Sie die Migration ausgeführt haben.

• Wenn Sie die Migration mit GitHub CLI ausgeführt haben, zeigt der Prozess standardmäßig an, ob die Migration erfolgreich war oder fehlgeschlagen ist, sobald die Migration abgeschlossen ist. Wenn die Migration fehlgeschlagen ist, wird der Grund für einen Fehler angezeigt.

  Migration completed (ID: RM_123)! State: SUCCEEDED
  

• Wenn Sie die Migration mit GitHub CLI mit dem optionalen --queue-only-Argument ausgeführt haben, wird der Prozess unmittelbar nach dem Einstellen in die Warteschlange der Migration beendet und teilt Ihnen nicht mit, ob die Migration erfolgreich war oder fehlgeschlagen ist. Sie können den Status einer Migration mithilfe des wait-for-migration-Befehls überprüfen oder das Migrationsprotokoll überprüfen.

• Wenn Sie die Migration mit der GraphQL-API ausgeführt haben, können Sie die Felder state und failureReason des RepositoryMigration-Objekts abfragen.

Wenn die Migration fehlgeschlagen ist, enthält das Migrationsprotokoll möglicherweise zusätzliche Informationen zur Ursache des Fehlers. Weitere Informationen findest du unter Prüfen des Migrationsprotokolls.

Überprüfen des Migrationsprotokolls

Überprüfen Sie das Migrationsprotokoll für jedes migrierte Repository. Weitere Informationen finden Sie unter Zugreifen auf die Migrationsprotokolle für GitHub Enterprise Importer.

Wenn die Migration fehlgeschlagen ist, enthält das Protokoll möglicherweise zusätzliche Informationen zur Ursache des Fehlers.

Wenn die Migration erfolgreich war, gibt es möglicherweise Warnungen im Migrationsprotokoll, die bestimmte Datenelemente darstellen (z. B. Pull Requests, Probleme oder Kommentare), die nicht migriert oder mit Vorbehalten migriert wurden.

Weitere Informationen zum Verständnis von Migrationswarnungen findest du unter Behandeln von Problemen bei der Migration mit GitHub Enterprise Importer. Nach der Überprüfung von Migrationswarnungen müssen Sie entscheiden, ob Sie diese Warnungen akzeptieren und weitergehen können.

Sichtbarkeit eines Repositorys festlegen

Alle Repositorys werden standardmäßig als privat migriert, und nur die Person, die die Migration ausgeführt hat, sowie die Organisationsbesitzer*innen haben Zugriff auf das Repository. Wenn du nicht möchtest, dass das Repository privat ist, musst du seine Sichtbarkeit ändern.

• Die Sichtbarkeit eines Repositorys können Sie mit der CLI-Option --target-repo-visibility oder der GraphQL-Eigenschaft targetRepoVisibility festlegen.
• Du kannst die Sichtbarkeit eines Repositorys im Browser ändern. Weitere Informationen finden Sie unter Sichtbarkeit eines Repositorys festlegen.
• Alternativ kannst du mit GitHub CLI die Sichtbarkeit des Repositorys über die Befehlszeile ändern. Du kannst diesen Befehl sogar dem Skript hinzufügen, das zum Ausführen deiner Migrationsvorgänge generiert wurde. Weitere Informationen findest Du gh repo edit in der Dokumentation zur GitHub CLI.

Konfigurieren von Berechtigungen

Da Berechtigungen in GitHub anders funktionieren als in ADO, versucht GitHub Enterprise Importer nicht, Repositoryberechtigungen von ADO zu migrieren.

Wenn du die ADO2GH-Befehlszeilenschnittstelle verwendet hast, erstellt GitHub Enterprise Importer zwei Teams in GitHub für jedes Teamprojekt in ADO. Jedem Team wird eine andere Zugriffsebene auf alle Repositorys gewährt, die aus dem Teamprojekt stammen.

Team	Zugriff auf migrierte Repositorys
TEAM-PROJECT-Maintainer*innen	Maintainer (Teambetreuer)
TEAM-PROJECT-Administrator*innen	Administrator

Um Zugriff auf migrierte Repositorys zu gewähren, kannst du diesen Teams Personen hinzufügen. Dies kann manuell in GitHub erfolgen. Wenn du die Teams während deiner Migration mit Azure Active Directory-Gruppen (AAD) verknüpfen möchtest, kannst du dies auch über die Gruppenmitgliedschaft in AAD verwalten. Weitere Informationen zur manuellen Verwaltung der Teammitgliedschaft findest du unter Organisationsmitglieder zu einem Team hinzufügen.

Wenn du die ADO2GH-Befehlszeilenschnittstelle nicht verwendest oder wenn du eine Berechtigungskonfiguration benötigst, die über diese Standardeinstellung hinaus geht, konfigurierst du Berechtigungen für deine migrierten Repositorys. Du kannst das Migrationsskript an deine Anforderungen anpassen oder Berechtigungen nach der Migration manuell konfigurieren. Weitere Informationen zum Verwalten des Zugriffs auf Repositorys in GitHub findest du unter Repositoryrollen für eine Organisation.

1. Entscheide, welche Berechtigungsstruktur du in GitHub benötigst.
2. Wenn sie sich von der Standardeinstellung unterscheidet, erstelle einen Plan zum Einrichten der Teammitgliedschaft und der Berechtigungen.

Freigeben von Mannequins

Nachdem du eine Migration mit dem GitHub Enterprise Importer ausgeführt hast, werden alle Benutzeraktivitäten im migrierten Repository (mit Ausnahme von Git-Commits) Platzhalteridentitäten zugeordnet, die als Mannequins bezeichnet werden.

Du kannst den Verlauf für jedes Mannequin einem Organisationsmitglied mit GitHub CLI oder im Browser neu zuordnen. Wenn du die GitHub CLI verwendest, kannst du Mannequins in einem Massenvorgang freigeben. Weitere Informationen findest du unter Freigeben von Mannequins für GitHub Enterprise Importer.

1. Entscheide, ob du Mannequins freigeben möchtest.
2. Plane, wann du die Freigaben abschließen möchtest.
3. Gib die Mannequins frei.
4. Wenn eines der Mitglieder nicht bereits durch seine Teammitgliedschaft über den erforderlichen Zugriff auf das Repository verfügt, gewähre den Mitgliedern Zugriff auf das Repository. Weitere Informationen finden Sie unter Den Zugriff einer Person auf ein Repository einer Organisation verwalten.

Konfigurieren von IP-Zulassungslisten

Wenn du der Liste zugelassener IP-Adressen für deine Zielorganisationen die IP-Adressbereiche für GitHub Enterprise Importer hinzugefügt hast, kannst du diese Einträge entfernen. Wenn du die Einschränkungen durch die Liste zulässiger IP-Adressen deines Identitätsanbieters für dein Zielunternehmen deaktiviert hast, kannst du sie jetzt erneut aktivieren.

Weitere Informationen finden Sie unter Verwalten des Zugriffs für eine Migration von Azure DevOps.