Informationen zu Organisationsmigrationsvorgängen mit GitHub Enterprise Importer
Du kannst deine Migration entweder mit der GitHub CLI oder mit der API ausführen.
Die GitHub CLI vereinfacht den Migrationsprozess und wird für die meisten Kundinnen empfohlen. Fortgeschrittene Kundinnen, die viele Anpassungen vornehmen müssen, können die API verwenden, um eigene Integrationen mit dem GitHub Enterprise Importer zu erstellen.
Voraussetzungen
- Es wird dringend empfohlen, einen Testlauf deiner Migration durchzuführen und die Produktionsmigration bald danach abzuschließen. Mehr über Testläufe erfahren Sie unter Übersicht über die Migration zwischen GitHub-Produkten.
- Stellen Sie sicher, dass Sie die zu migrierenden Daten und die bekannten Supportbeschränkungen des Importer verstehen. Weitere Informationen finden Sie unter Informationen zu Migrationen zwischen GitHub-Produkten.
- Es ist zwar nicht erforderlich, die Arbeit während der Produktionsmigration zu unterbrechen, es wird aber empfohlen. Der Importer unterstützt keine Deltamigrationen, sodass Änderungen, die während der Migration vorgenommen werden, nicht migriert werden. Wenn du dich dafür entscheidest, die Arbeit während der Produktionsmigration nicht zu unterbrechen, musst du diese Änderungen manuell migrieren.
- Für die Quellorganisation musst du Organisationsbesitzer*in sein oder dir muss die Migrator-Rolle zugewiesen sein. Weitere Informationen findest du unter Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten.
- Darüber hinaus musst du Unternehmensbesitzer*in für das Zielunternehmenskonto sein.
Schritt 0: Vorbereiten der Verwendung der GraphQL-API von GitHub
Um GraphQL-Abfragen zu erstellen, musst du eigene Skripts schreiben oder einen HTTP-Client wie Insomnia verwenden.
Weitere Informationen zu den ersten Schritten mit der GitHub-GraphQL-API, einschließlich der Authentifizierung, findest du unter Erstellen von Aufrufen mit GraphQL.
Schritt 1: Abrufen der Unternehmens-ID für dein Migrationsziel
Verwende als Unternehmensbesitzer*in in GitHub.com die folgende Abfrage, um die ID für das Unternehmenskonto auszugeben, das die migrierte Organisation besitzen soll. Du benötigst die Unternehmens-ID, um das Migrationsziel anzugeben.
query(
$slug: String!
){
enterprise (slug: $slug)
{
slug
id
}
}
Abfragevariable | Beschreibung |
---|---|
slug | Der Slug für dein Unternehmenskonto. Du findest ihn in der URL für dein Unternehmen: https://github.com/enterprises/SLUG . |
Schritt 2: Starten der Organisationsmigration
Wenn du eine Migration beginnst, werden eine einzelne Organisation und die zugehörigen Daten in eine neue Organisation innerhalb des von dir festgelegten Zielunternehmens migriert.
mutation startOrganizationMigration (
$sourceOrgUrl: URI!,
$targetOrgName: String!,
$targetEnterpriseId: ID!,
$sourceAccessToken: String!,
$targetAccessToken: String!
){
startOrganizationMigration( input: {
sourceOrgUrl: $sourceOrgUrl,
targetOrgName: $targetOrgName,
targetEnterpriseId: $targetEnterpriseId,
sourceAccessToken: $sourceAccessToken,
targetAccessToken: $targetAccessToken
}) {
orgMigration {
id
}
}
}
Abfragevariable | Beschreibung |
---|---|
sourceOrgUrl | Die URL der Quellorganisation, z. B. https://github.com/octo-org |
targetOrgName | Der Name, den du der neuen Organisation geben willst. Muss auf GitHub.com eindeutig sein. |
targetEnterpriseId | Die ID des Unternehmens, in dem du die neue Organisation erstellen möchten, wie in Schritt 2 ausgegeben |
sourceAccessToken | Dein personal access token für die Quellorganisation. Informationen zu den Anforderungen findest du unter Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten. |
targetAccessToken | Dein personal access token für das Zielunternehmen |
Im nächsten Schritt verwendest du die von der startOrganizationMigration
-Mutation zurückgegebene Migrations-ID, um den Migrationsstatus zu überprüfen.
Schritt 3: Überprüfen des Migrationsstatus
Um Migrationsfehler zu erkennen und sicherzustellen, dass deine Migration funktioniert, kannst du die erstellte(n) OrganizationMigration
(en) abfragen und den Migrationsstatus mithilfe der getMigration
-Abfrage anzeigen.
Die Abfrage gibt einen Status aus, der dich darüber informiert, ob die Migration queued
, in progress
, failed
, oder completed
ist, sowie darüber, wie viele Repositorys auf die Migration warten. Wenn die Migration fehlerhaft war, gibt der Importer einen Grund für den Fehler an.
query (
$id: ID!
){
node( id: $id ) {
... on OrganizationMigration {
id
sourceOrgUrl
targetOrgName
state
failure_reason
remaining_repositories_count
total_repositories_count
}
}
}
Abfragevariable | Beschreibung |
---|---|
id | Die id deiner Migration |
Schritt 1: Installieren der GEI extension of the GitHub CLI
Wenn dies deine erste Migration ist, musst du die GEI extension of the GitHub CLI installieren. Weitere Informationen zur GitHub CLI findest du unter Informationen zur GitHub CLI.
-
Installiere die GitHub CLI. Installationsanweisungen für GitHub CLI findest du im GitHub CLI-Repository.
Hinweis: Du benötigst Version 2.4.0 oder höher der GitHub CLI. Die installierte Version kannst du mit dem Befehl
gh --version
ermitteln. -
Installiere die GEI extension.
Shell gh extension install github/gh-gei
gh extension install github/gh-gei
Wenn du Hilfe zur GEI extension benötigst, kannst du immer das Flag --help
mit einem Befehl verwenden. Mit gh gei --help
listest du z. B. alle verfügbaren Befehle auf, und mit gh gei migrate-repo --help
zeigst du alle Optionen an, die für den Befehl migrate-repo
verfügbar sind.
Schritt 2: Aktualisieren der GEI extension of the GitHub CLI
Die GEI extension wird wöchentlich aktualisiert. Aktualisieren die Erweiterung, um sicherzustellen, dass du die neueste Version verwendest.
gh extension upgrade github/gh-gei
Schritt 3: Festlegen der Umgebungsvariablen
Bevor du GEI extension zum Migrieren von GitHub Enterprise Cloud verwenden kannst, musst du personal access tokens erstellen, die auf die Quellorganisation und das Zielunternehmen zugreifen können und dann die personal access tokens als Umgebungsvariable festlegen.
-
Erstelle ein personal access token, das alle Authentifizierungsanforderungen der Quellorganisation für Organisationsmigrationen erfüllt, und zeichne es auf. Weitere Informationen findest du unter Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten.
-
Erstelle ein personal access token, das alle Authentifizierungsanforderungen des Zielunternehmen für Organisationsmigrationen erfüllt, und zeichne es auf.
-
Lege Umgebungsvariablen für die personal access tokens fest, und ersetze in den folgenden Befehlen TOKEN durch die personal access tokens, die du oben gespeichert hast. Verwende das
GH_PAT
für die Zielorganisation und dasGH_SOURCE_PAT
für die Quellorganisation.-
Wenn du ein Terminal verwendest, führe den Befehl
export
aus.Shell export GH_PAT="TOKEN" export GH_SOURCE_PAT="TOKEN"
export GH_PAT="TOKEN" export GH_SOURCE_PAT="TOKEN"
-
Wenn du PowerShell verwendest, führe den Befehl
$env
aus.Shell $env:GH_PAT="TOKEN" $env:GH_SOURCE_PAT="TOKEN"
$env:GH_PAT="TOKEN" $env:GH_SOURCE_PAT="TOKEN"
-
Schritt 4: Migrieren deiner Organisation
Verwende den gh gei migrate-org
-Befehl, um eine Organisation zu migrieren.
gh gei migrate-org --github-source-org SOURCE --github-target-org DESTINATION --github-target-enterprise ENTERPRISE
gh gei migrate-org --github-source-org SOURCE --github-target-org DESTINATION --github-target-enterprise ENTERPRISE
Ersetze die Platzhalter im obigen Befehl durch die folgenden Werte.
Platzhalter | Wert |
---|---|
SOURCE | Name der Ursprungsorganisation |
DESTINATION | Der Name, den du der neuen Organisation geben willst. Muss auf GitHub.com eindeutig sein. |
ENTERPRISE | Der Slug für dein Zielunternehmen. Du findest ihn in der URL für dein Unternehmenskonto: https://github.com/enterprises/SLUG . |
Schritt 5: Überprüfen der Migration und des Fehlerprotokolls
Es empfiehlt sich, nach Abschluss der Migration das Migrationsprotokollrepository zu überprüfen. Weitere Informationen findest du unter Zugreifen auf die Migrationsprotokolle für GitHub Enterprise Importer.
Als letzten Schritt solltest du eine Überprüfung der Integrität deiner Organisation und der migrierten Repositorys vornehmen.