Phase 1. Grundlegendes zu Migrationen von Azure DevOps zu GitHub

GitHub Enterprise Importer kann die Migration von Azure DevOps automatisieren.

In diesem Artikel

Informationen zu Migrationen von Azure DevOps Cloud

Du kannst GitHub Enterprise Importer verwenden, um Repositorys von Azure DevOps zu GitHub Enterprise Cloud (GitHub.com oder GHE.com) zu migrieren.

Du kannst GitHub Enterprise Importer nur verwenden, um von Azure DevOps Cloud zu migrieren, nicht von Azure DevOps Server. Wenn du derzeit Azure DevOps Server verwendest und zu GitHub migrieren möchtest, kannst du zuvor zu Azure DevOps Cloud migrieren. Weitere Informationen findest du auf der Azure-Website unter Migrieren zu Azure DevOps.

Bevor Sie Ihr Unternehmenskonto auf GitHub erstellen, müssen Sie entscheiden, ob Ihr Unternehmen Enterprise Managed Users verwenden wird. Dies wirkt sich darauf aus, wie Sich Ihre Mitglieder authentifizieren und wie Sie Identitäten und Zugriff verwalten. Weitere Informationen findest du unter Auswählen eines Unternehmenstyps für GitHub Enterprise Cloud.

Unterstützung für Azure Pipelines und Azure Boards

Sowohl Azure-Pipelines als auch Azure-Boards können vollständig in Ihre GitHub Erfahrung integriert werden. Sie können Ihr Unternehmenskonto und Azure DevOps so konfigurieren, dass Sie diese Dienste weiterhin verwenden und gleichzeitig davon profitieren können, dass Ihre Repositorys auf GitHub gehostet werden.

Wenn du von Azure Pipelines zu GitHub Actions migrieren möchtest, wende dich an deinen GitHub-Kontomanagerin.

Migrierte Daten

GitHub Enterprise Importer unterstützt derzeit die Migration der folgenden Repositorydaten von Azure DevOps zu GitHub Enterprise Cloud.

  • Git-Quelle (einschließlich Commitverlauf)
  • Pull Requests
  • Benutzerverlauf für Pull Requests
  • Arbeitselement-Links in Pull Requests
  • Anhänge bei Pull Requests
  • Branch-Richtlinien für das Repository (benutzerspezifische Branch-Richtlinien und Repo-übergreifende Branch-Richtlinien für Repositorys sind nicht enthalten)

Einschränkungen bei migrierten Daten

Es gelten Einschränkungen dafür, was GitHub Enterprise Importer migrieren kann. Einige sind auf Einschränkungen von GitHub zurückzuführen, während andere Einschränkungen durch GitHub Enterprise Importer selbst verursacht werden.

Einschränkungen von GitHub

  •         **2 GiB-Größenbeschränkung für einen einzelnen Git-Commit:** Kein einzelner Commit in Ihrem Git-Repository kann größer als 2 GiB sein. Wenn eines Ihrer Commits größer als 2 GiB ist, müssen Sie den Commit in kleinere Commits aufteilen, die jeweils 2 GiB oder kleiner sind.

  •         **Grenzwert von 255 Byte für Git-Verweise:** Kein einzelner Git-Verweis, der allgemein als "Ref" bezeichnet wird, kann einen Namen haben, der größer als 255 Byte ist. In der Regel bedeutet dies, dass Ihre Verweise nicht mehr als 255 Zeichen lang sind, aber alle Nicht-ASCII-Zeichen, z. B. Emojis, können mehr als ein Byte verbrauchen. Wenn einer deiner Git-Verweise zu groß ist, wird eine eindeutige Fehlermeldung zurückgegeben.

  •         **Dateigrößenbeschränkung von 100 MiB:** Nach Abschluss der Migration kann keine einzelne Datei in Ihrem Git-Repository größer als 100 MiB sein. Während der Repositorymigration wird dieser Grenzwert auf 400 MiB erhöht. Erwäge die Verwendung von Git LFS zum Speichern großer Dateien.

Einschränkungen von GitHub Enterprise Importer

  • Grenzwert für die Größe von 40 GB für ein Git-Repository (öffentliche Vorschau): Dieser Grenzwert gilt nur für den Quellcode. Um zu überprüfen, ob das Repositoryarchiv den Grenzwert überschreitet, verwenden Sie das Git-Sizer-Tool, und überprüfen Sie die Gesamt-BLOB-Größe in der Ausgabe. Das Git-Sizer-Tool hilft auch, potenzielle Probleme im Zusammenhang mit großen Dateien, BLOB-Größe, Commit-Größe und Strukturanzahl zu identifizieren, die sich auf Migrationen auswirken könnten.
  •         **Grenzwert von 400 MiB für die Dateigröße:** Beim Migrieren eines Repositorys mit GitHub Enterprise Importer darf keine einzelne Datei in deinem Git-Repository größer als 400 MiB sein. Erwäge die Verwendung von Git LFS zum Speichern großer Dateien.

  •         **Git LFS-Objekte werden nicht migriert:** Importer kann Repositorys migrieren, die Git LFS verwenden, aber die LFS-Objekte selbst werden nicht migriert. Sie können nach Abschluss der Migration als Folgeaufgabe an dein Migrationsziel verschoben werden.

  •         **Verzögerte Funktionalität der Codesuche:** Die erneute Indizierung des Suchindex kann einige Stunden dauern, nachdem ein Repository migriert wurde, und die Codesuche kann unerwartete Ergebnisse zurückgeben, bis die erneute Indizierung abgeschlossen ist.

  •         **Für deine Organisation konfigurierte Regelsätze können zu Migrationsfehlern führen**: Wenn du beispielsweise eine Regel konfiguriert hast, die voraussetzt, dass E-Mail-Adressen von Commitautor*innen mit `@monalisa.cat` enden, und das zu migrierende Repository Commits enthält, die dieser Regel nicht entsprechen, schlägt die Migration fehl.

  •         **Mannequin-Inhalte sind möglicherweise nicht durchsuchbar**: Mannequins sind Platzhalterbenutzer, denen importierte Inhalte (z. B. Probleme, Pull Requests, Kommentare usw.) zugeordnet sind. Wenn Sie nach Inhalten suchen, die einem Modell zugeordnet sind, z.B. zugewiesene Probleme, können diese möglicherweise nicht gefunden werden. Sobald ein Mannequin zurückgenommen wird, sollte der Inhalt über den neuen Besitzer gefunden werden.

Nächste Schritte

Im nächsten Artikel entscheiden Sie, wer die Migration durchführt und bereiten den Zugriff auf Azure DevOps und GitHub Enterprise Cloud vor. Weitere Informationen findest du unter Phase 2. Verwalten des Zugriffs.