Ü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.
- Migrieren von Repositorys von ADO zu GitHub
- Migrieren von Pipelines von Azure Pipelines zu GitHub Actions
- 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.
- Bestimme, wie viele Repositorys und Pull Requests du migrieren musst.
- Um zu verstehen, wann die einzelne Teams für die Migration bereit sein können, solltest du mit allen Projektbeteiligten reden.
- 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