Übersicht über die Migration von Butbucket Server zu GitHub Enterprise Cloud

Erfahren Sie, wie Sie den gesamten Prozess der Migration von Bitbucket Server zu GitHub mit GitHub Enterprise Importer von der Planung über die Implementierung bis hin zum Abschluss von Folgeaufgaben durchführen.

In diesem Artikel

Übersicht

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

Wenn du von Bitbucket Server migrierst, kannst du diesen Leitfaden verwenden, um deine Migration zu planen und zu implementieren und Folgeaufgaben durchzuführen.

Planen der Migration

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

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

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 Bitbucket Server migriert GitHub Enterprise Importer nur Git-Repositorys und Pull Requests. Alle anderen Ressourcen, z. B. CI-Pipelines, verbleiben in Bitbucket Server.

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

  1. Überprüfe die Daten, die von Bitbucket Server migriert werden. Weitere Informationen findest du unter Informationen zu Migrationen von Butbucket Server 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 in GitHub sein, oder dir muss von einem/einer Organisationsbesitzerin die Migrationsrolle zugewiesen worden sein.

Außerdem musst du über die erforderlichen Berechtigungen für deine Bitbucket Server-Instanz verfügen und Zugriff darauf haben:

  • Admin- oder Superadministratorberechtigungen
  • Wenn auf deiner Bitbucket Server-Instanz Linux ausgeführt wird, greifst du mit SFTP auf die Instanz mithilfe eines unterstützten privaten SSH-Schlüssels zu (siehe "Verwalten des Zugriffs für eine Migration von Bitbucket Server").
  • Wenn auf deiner Bitbucket Server-Instanz Windows ausgeführt wird, kannst du per Dateifreigabe (SMB) auf die Instanz zugreifen.
  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 sind unter „Verwalten des Zugriffs für eine Migration von Bitbucket Server“ zu finden.
  4. Vergewissere dich, dass die Person die personal access token ordnungsgemäß konfiguriert hat, sodass sie alle Zugriffsanforderungen erfüllen. Weitere Informationen sind unter „Verwalten des Zugriffs für eine Migration von Bitbucket Server“ zu finden.
  5. Vergewissere dich, dass der Migrationscomputer über Administrator- oder Superadministratorberechtigungen und SFTP-Zugriff für deine Bitbucket Server-Instanz verfügt.

Welche Organisationsstruktur möchtest du in GitHub verwenden?

Plane als Nächstes, welche Organisationsstruktur du in GitHub erstellen möchtest.

In Bitbucket Server werden Repositorys in Projekten gruppiert. In GitHub sind Repositorys im Besitz von Organisationen. Du solltest jedoch nicht davon ausgehen, dass der beste Ansatz darin besteht, pro Projekt in Bitbucket Server eine Organisation in GitHub zu erstellen.

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.

Jedes migrierte Repository befindet sich im Besitz einer dieser Organisationen. Dies kann zu sehr vielen nicht gruppierten Repositorys innerhalb jeder Organisation führen. Du kannst jedoch den Zugriff auf Repositorygruppen verwalten, indem die in GitHub Teams erstellst. Weitere Informationen findest du unter Informationen zu Teams.

Wenn du deinen Migrationsaufwand in Batches aufteilen möchtest, solltest du die Batchverarbeitung nach Organisation in Betracht ziehen.

  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 sind unter „Verwalten des Zugriffs für eine Migration von Bitbucket Server“ zu finden.
  7. Führe deine Produktionsmigrationen aus. Weitere Informationen findest du unter Migrieren von Repositorys von Bitbucket Server 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 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 finden Sie unter „Prüfen des Migrationsprotokolls“.

Überprüfen des Migrationsprotokolls

Überprüfen Sie das Migrationsprotokoll für jedes migrierte Repository. Weitere Informationen findest du 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 finden Sie 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 findest du 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 Bitbucket Server, versucht GitHub Enterprise Importer nicht, Repositoryberechtigungen von Bitbucket Server zu migrieren.

Um Zugriff auf migrierte Repositorys zu gewähren, kannst du Teams erstellen und jedem Team Zugriff auf das Repository gewähren.

  1. Erstelle Teams. Weitere Informationen findest du unter Ein Team erstellen.
  2. Füge Organisationsmitglieder zu Teams hinzu. Weitere Informationen findest du unter Organisationsmitglieder zu einem Team hinzufügen.
  3. Gewähre jedem Team Zugriff auf das Repository. Weitere Informationen findest du unter Den Teamzugriff auf ein Repository einer Organisation verwalten.

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.

Hinweis: Nur Organisationsbesitzerinnen können Mannequins freigeben. Wenn dir die Rolle „Migrator“ zugewiesen wurde, wende dich an die Organisationsbesitzerinnen, um diesen Schritt auszuführen.

  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 findest du 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 findest du unter Verwalten des Zugriffs für eine Migration von Bitbucket Server.