Migrieren Ihres Repositorys mit Enterprise Live-Migrationen

Voraussetzungen

Stellen Sie sicher, dass Sie für Ihre Migration bereit sind. Siehe Vorbereiten der Livemigration von GitHub Enterprise Server zu GHE.com.

1. Erstellen von Zugriffstoken

Sie müssen sich mit einem personal access token (classic) sowohl für die Quelle als auch für das Ziel der Migration authentifizieren. Ausführliche Anweisungen findest du unter Verwalten deiner persönlichen Zugriffstoken.

          **Notieren Sie sich beide Token**, da Sie sie im nächsten Schritt benötigen.

1. Erstellen Sie ein personal access token (classic) auf GitHub Enterprise Server mit folgenden Bereichen.

   • repo
   • admin:org
   • admin:repo_hook
   • admin:org_hook

2. Erstellen Sie ein personal access token (classic) auf GHE.com mit den folgenden Bereichen.

   • repo
   • workflow
   • admin:org
   • admin:repo_hook
   • admin:enterprise

3. Wenn einmaliges Anmelden für die Zielorganisation GHE.comerzwungen wird, autorisieren Sie das GHE.com Token.

2. Konfigurieren GitHub Enterprise Server

Sie müssen eine Konfiguration für die GitHub Enterprise Server Instanz festlegen, bevor Sie eine Migration durchführen. Diese Konfigurationswerte gelten für alle ELM Migrationen. Entwickler auf GitHub Enterprise Server können eine kurze Ausfallzeit feststellen, wenn Sie die neue Konfiguration anwenden.

1. Greifen Sie über SSH auf die GitHub Enterprise Server Verwaltungsshell zu. Siehe Auf die Verwaltungsshell (SSH) zugreifen.

2. Legen Sie die folgenden Konfigurationsvariablen mit ghe-config fest.

   Beispiel: ghe-config app.elm-exporter.enabled true

   Variable	Legen Sie dies auf...
   app.elm-exporter.enabled	true
   app.elm.internal-webhooks-enabled	true
   app.elm-exporter.webhooks-loopback-address-enabled	true
   secrets.elm-exporter.migration-target-url	Die API-URL für Ihr Zielunternehmen (z. B.: https://api.octocorp.ghe.com). Fügen Sie am Ende der URL keinen Schrägstrich hinzu.
   secrets.elm-exporter.migration-target-token	Das Zugriffstoken, für GHE.comdas Sie erstellt haben.
   secrets.elm-exporter.source-token	Das Zugriffstoken, für GitHub Enterprise Serverdas Sie erstellt haben.
   secrets.elm-exporter.source-user	Der dem Token zugeordnete GitHub Enterprise Server Benutzername (z. B.: ghe-admin).

3. Wenn Sie noch keine Migrationen aktiviert haben und Blob-Speicher auf der Instanz konfiguriert ist, können Sie diese jetzt konfigurieren. Sie können Ihre vorhandenen Einstellungen im Abschnitt "Migrationen" der Verwaltungskonsole (HOSTNAME/setup/settings) überprüfen.

   Sie können die folgenden Standardwerte verwenden, die keine unerwarteten Funktionen enthalten.

   Shell

   ghe-config app.migrations.enabled true
   

   Shell

   ghe-config secrets.migrations.blob-storage-type local-storage
   

4. Wende die Konfiguration an.

   Shell

   ghe-config-apply
   

3. Festlegen erforderlicher Umgebungsvariablen

Wenn die Konfiguration angewendet wurde und bevor Sie eine Migration starten, legen Sie erforderliche Umgebungsvariablen fest. Beispiel:

export API_URL='http://localhost:1738'

Jeder dieser Werte kann auch als CLI-Flags für jeden elm Befehl bereitgestellt werden, der Vorrang vor den Variablen hat. Beispiel: --api-url http://localhost:1738.

4. Erstellen Sie eine Migration

Erstellen Sie eine neue Migration, indem Sie die Quell- und Ziel-Repositorydetails angeben. --pat-name muss als statischer Wert auf system-pat festgelegt werden. Die anderen Werte sind Platzhalter, die für Ihre Umgebung spezifisch sind.

elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO \
  --target-api GHEC-API-URL \
  --pat-name system-pat

elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO \
  --target-api GHEC-API-URL \
  --pat-name system-pat

Beispiel:

elm migration create \
  --source-org my-ghes-org \
  --source-repo my-ghes-repo \
  --target-org my-dr-org \
  --target-repo my-dr-repo \
  --target-api $MIGRATION_TARGET_URL \
  --pat-name system-pat

Optionale Kennzeichnungen:

• --start: Wenn Sie bereit sind, die Migration sofort zu starten.
• --target-visibility: Migrierte Repositorys werden standardmäßig mit interner Sichtbarkeit erstellt, aber Sie können angeben private.

Speichern der Migrations-ID

Es sollte eine Antwort wie folgt angezeigt werden:

{
  "migrationId": "2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9",
  "expiresAt": "2026-02-11T21:49:33.619162159Z"
}

Exportieren Sie die migrationId Variable, da Sie sie für die nächsten Befehle benötigen. Beispiel:

export MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9'

5. Starten der Migration

Wenn Sie die Migration noch nicht gestartet haben, starten Sie sie jetzt mit der soeben gespeicherten Migrations-ID.

elm migration start --migration-id $MIGRATION_ID

elm migration start --migration-id $MIGRATION_ID

Dadurch werden die Backfill- und Liveupdateprozesse gestartet. ELM erfasst nun Daten aus dem Quell-Repository und lauscht auf unterstützte Webhook-Ereignisse.

6. Überwachen der Migration

Wenn die Migration gestartet wurde, sollte ein neues Repository GHE.com angezeigt werden. Während der Migration sehen Sie, dass das Repository mit einer anfänglichen Auslastung von Daten gefüllt wird und Updates empfängt, während Entwickler weiterhin im Quell-Repository arbeiten.

Führen Sie den folgenden Befehl regelmäßig aus, um den Migrationsstatus zu überwachen. Es wird eine Aufschlüsselung der Status der Quelle und des Ziels sowie Informationen zu den zu migrierenden Livedaten angezeigt.

elm migration status --migration-id $MIGRATION_ID

elm migration status --migration-id $MIGRATION_ID

Der wichtigste Indikator in der Antwort ist der Status im combinedState-Objekt . Wenn der Status erreicht ist COMBINED_STATUS_READY_FOR_CUTOVER, sollten Sie bereit sein, mit dem nächsten Schritt fortzufahren. Sie werden jedoch benachrichtigtdisplayMessage, wenn einzelne Ressourcen nicht migriert werden konnten, die möglicherweise einer Untersuchung bedürfen.

Beispiel:

  "combinedState":  {
    "status":  "COMBINED_STATUS_READY_FOR_CUTOVER",
    "displayMessage":  "Ready for cutover (1 resources failed)",
    "repositories":  [
      {
        "repositoryNwo":  "new-test-org/my-new-repo",
        "phase":  "REPOSITORY_PHASE_READY_FOR_CUTOVER",
        "displayStatus":  "Ready for cutover (1 failed)"
      }
    ],
    "readyForCutover":  true,
    "cutoverBlockers":  []
  },

Tipps:

• Wenn Sie mehrere Migrationen ausführen, können Sie den Status aller Migrationen überprüfen.elm migration list Dieser Befehl zeigt standardmäßig laufende Migrationen an, Sie können aber auch nach --statusfiltern.
• Wenn Fehlerstatus auftreten, die Aufmerksamkeit erfordern, siehe Problembehandlung bei Livemigrationen von GitHub Enterprise Server zu GHE.com.

7. Abschließen der Migration

Wenn eine Migration für die Umstellung bereit ist, können Sie die Migration abschließen. Der Übernahmevorgang sperrt das Quell-Repository, sodass es für Entwickler dauerhaft nicht verfügbar ist, es sei denn, ein Administrator entsperrt es.

elm migration cutover-to-destination --migration-id $MIGRATION_ID

elm migration cutover-to-destination --migration-id $MIGRATION_ID

Fahren Sie mit der Überwachung der Migration fort. Wenn der MIGRATION_STATUS_COMPLETED Status oben in der Antwort angezeigt wird, ist die Migration abgeschlossen, obwohl es einige Folgeaufgaben gibt, um Benutzern Zugriff von GitHub Enterprise Server zu gewähren.

Nächste Schritte

Gewähren Sie Benutzern Zugriff auf das neue Repository und stimmen Sie Aktivitäten mit Benutzerkonten ab. Siehe Abschließen der Livemigration von GitHub Enterprise Server zu GHE.com.