Migrieren Ihres Repositorys mit Enterprise Live-Migrationen

Voraussetzungen

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

1. Konfigurieren GitHub Enterprise Server

Sie müssen eine Konfiguration für die GitHub Enterprise Server Instanz festlegen, bevor Sie Token erstellen und 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.source-user	Der Benutzername, der dem Token des GitHub Enterprise Server Operators zugeordnet ist. Dies sollte Ihr Benutzername sein GitHub Enterprise Server; wenn eine andere Person dieses Token erstellt, sollte der Wert hier auf ihren Benutzernamen festgelegt werden. Wir empfehlen den ghe-admin Benutzer.

3. Wende die Konfiguration an.

   Shell

   ghe-config-apply
   

4. Verlassen Sie die SSH-Sitzung. Sie führen die restlichen Befehle in einer lokalen Terminalsitzung aus.

2. Erstellen von Operatortoken mit Unternehmenszugriff

Der Bediener muss sich sowohl beim Quellunternehmen als auch beim Zielunternehmen mit einem personal access token (classic) authentifizieren. Anweisungen zum Erstellen von Token finden Sie unter Verwalten deiner persönlichen Zugriffstoken.

Stellen Sie sicher, dass Sie beide Token notieren, da Sie sie im nächsten Schritt benötigen.

1. Erstellen Sie auf GitHub Enterprise Server ein personal access token (classic) und wählen Sie den erforderlichen Bereich aus:

   • admin:enterprise

   Sie verwenden dieses Token als Quelltoken beim Konfigurieren der ELM CLI.

2. Erstellen Sie auf GHE.com ein personal access token (classic) und wählen Sie die erforderlichen Bereiche aus:

   • admin:enterprise
   • admin:org

   Sie verwenden dieses Token beim Konfigurieren des **** als ELM CLI.

3. Konfigurieren des ELM Befehlszeilentools

Sie führen die Migration in einer lokalen Terminalsitzung mithilfe einer Erweiterung von GitHub CLI aus.

1. Installieren Sie GitHub CLI auf Ihrem lokalen Computer. Sie müssen Version 2.0 oder höher verwenden.

2. Installieren Sie die Erweiterung ELM.

   Shell

   gh extension install github/gh-elm
   

3. Starten Sie den Installations-Assistenten, um die Erweiterung zu konfigurieren.

   Shell

   gh elm configure
   

4. Befolgen Sie die Anweisungen im Installations-Assistenten, und stellen Sie die API-URLs (z. B. : https://api.SUBDOMAIN.ghe.com) für Ihre Quelle und Ihr Ziel und die Token bereit, die Sie im vorherigen Schritt erstellt haben.

Jeder dieser Werte kann auch als CLI-Flags für jeden gh elm Befehl bereitgestellt werden, der Vorrang vor der Konfiguration hat. Beispiel: --target-url https://api.SUBDOMAIN.ghe.com.

Dieser Setupvorgang speichert die URLs in einer plattformspezifischen Konfigurationsdatei im Konfigurationsverzeichnis Ihres Betriebssystems unter gh-elm/config.json. Die Zugriffstoken werden sicher im geheimen Speicher Ihres Computers gespeichert.

4. Konfigurieren Sie die Secrets für die Live-Migration

Zusätzlich zu den Operatortoken mit Unternehmenszugriff müssen Sie eine personal access token (classic) für die Quell- und Zielorganisationen erstellen. Sie müssen diese Schritte für jede Organisation wiederholen, von der Sie migrieren.

Erstellen von Zugriffstoken

ELM muss sich sowohl für die Quelle als auch für das Ziel der Migration bei personal access token (classic) authentifizieren. Anweisungen zum Erstellen von Token finden Sie unter Verwalten deiner persönlichen Zugriffstoken.

Stellen Sie sicher, dass Sie diese Token notieren, da Sie sie im nächsten Schritt benötigen.

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

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

   Dies ist Ihr Quelltoken.

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

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

   Dies ist Ihr Zieltoken.

   Wichtig

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

Konfigurieren Sie die Geheimnisse Ihrer Organisation ELM

Verwenden Sie die gh elm config Befehle, um die Quell- und Zielzugriffstoken festzulegen:

1. Legen Sie das Quelltoken fest.

   Shell

   gh elm config set-source-pat EXISTING-GHES-ORG
   

   Fügen Sie das Quell-Token in das Terminal ein, wenn Sie dazu aufgefordert werden.

2. Legen Sie das Zieltoken fest.

   Shell

   gh elm config set-target-pat EXISTING-GHES-ORG
   

   Fügen Sie das Zieltoken bei Aufforderung in das Terminal ein.

Sie können die Token auch interaktiv, mithilfe gh elm config org-tokens EXISTING-GHES-ORGoder in den Organisationseinstellungen unter https://GHES_HOSTNAME/organizations/EXISTING-GHES-ORG/settings/secrets/elm-exporter/festlegen.

5. Eine Migration erstellen

Erstellen Sie eine neue Migration, indem Sie die Quell- und Ziel-Repositorydetails angeben.

gh elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO

gh elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO

Beispiel:

gh elm migration create \
  --source-org my-ghes-org \
  --source-repo my-ghes-repo \
  --target-org my-dr-org \
  --target-repo my-dr-repo

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'

6. Starten der Migration

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

gh elm migration start --migration-id $MIGRATION_ID

gh 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.

7. Ü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.

Sie können den Fortschritt der Migration interaktiv mit dem watch Befehl überwachen:

gh elm migration watch $MIGRATION_ID

Dadurch wird die Migrationsstatus-API abgerufen und eine selbst aktualisierende Textbenutzeroberfläche angezeigt, die den aktuellen Fortschritt widerspiegelt.

Programmgesteuerte Überwachung mithilfe von migration status

Wenn Sie einen zur Automatisierung geeigneten Migrationsstatus möchten, verwenden Sie den folgenden status Befehl:

gh elm migration status --migration-id $MIGRATION_ID

gh 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.gh 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.

8. Abschließen der Migration

Wenn eine Migration für die Umstellung bereit ist, können Sie die Migration abschließen. Der Übernahmevorgang archiviert das Quell-Repository und macht es dauerhaft schreibgeschützt , es sei denn, ein Repositoryadministrator hebt die Archivierung auf.

gh elm migration cutover --migration-id $MIGRATION_ID

gh elm migration cutover --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.