Phase 6. Nachverfolgungsaufgaben

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

Überprüfen des Migrationsprotokolls

Sie sollten das Migrationsprotokoll für jedes migrierte Repository überprüfen. Personen mit Lesezugriff auf ein Repository können auf das Migrationsprotokoll für das Repository in GitHub zugreifen.

Navigiere zum migrierten Repository in deiner Zielorganisation.
Klicke unter dem Repositorynamen auf Issues.
Klicke auf das Issue mit dem Titel „Migrationsprotokoll“.

Weitere Informationen finden Sie unter Zugriff auf die Migrationsprotokolle von GitHub Enterprise Importer.

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.

Du kannst die Sichtbarkeit eines Repositorys im Browser ändern. Weitere Informationen finden Sie unter Sichtbarkeit eines Repositorys festlegen.
Alternativ kannst du mit GitHub CLI die Sichtbarkeit des Repositorys über die Befehlszeile ändern. Weitere Informationen findest Du gh repo edit in der Dokumentation zur GitHub CLI.

Ersetzen Sie z. B. YOUR_ORG durch den Namen Ihrer Organisation, und der folgende Befehl legt alle Repositorys der Organisation auf die interne Sichtbarkeit fest.
Bash
```
export ORG=YOUR_ORG
gh repo list "$ORG" --limit 100000 --json name -q '.[].name' | xargs -I{} gh repo edit "$ORG/{}" --visibility internal
```
```
export ORG=YOUR_ORG
gh repo list "$ORG" --limit 100000 --json name -q '.[].name' | xargs -I{} gh repo edit "$ORG/{}" --visibility internal
```

Freigeben von Mannequins

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.

Konfigurieren von Azure-Pipelines und Azure Boards

Wenn Sie Zuvor Azure Pipelines oder Azure Boards verwendet haben und diese weiterhin mit Ihren Repositorys verwenden möchten, werden sie jetzt auf GitHubgehostet, können Sie diesen Leitfäden in Microsoft Learn folgen, um die relevante Erweiterung zu konfigurieren.

        [Verbinden von Azure-Pipelines mit GitHub](https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/github)

        [Konfigurieren der Azure Boards-App für GitHub](https://learn.microsoft.com/en-us/azure/devops/boards/github/install-github-app)

Unterstützen Ihrer Entwickler in ihrer neuen Umgebung

Es gibt einige Unterschiede zwischen Azure DevOps und GitHub die für Sie und Ihre Entwickler hilfreich sein würden. Teilen Sie Wichtige Unterschiede zwischen Azure DevOps und GitHub mit ihnen.

In diesem Artikel