1. Erfahren Sie mehr über Enterprise Live-Migrationen

Azure DevOps Services

Enterprise Live Migrations (ELM) unterstützt Sie bei der Migration von Azure-DevOps-Repositorien zu GitHub Enterprise Cloud mit Datenresidenz bei minimalen Unterbrechungen. ELM synchronisiert die Quell- und Zielrepositorien kontinuierlich, sodass Ihre Teams in Azure DevOps Services weiterarbeiten können, bis Sie für die Umstellung bereit sind. Es gibt zwei Migrationspfade: Übernahme vollständig auf GitHub oder Verwenden eines Hybridmodells, bei dem Quellcode zu GitHub wechselt, während Teams weiterhin Azure Boards und Azure Pipelines verwenden.

ELM steht in zwei Umgebungen zur Verfügung: die Azure DevOps CLI und das Azure DevOps-Portal. Verwenden Sie die CLI, wenn Sie Migrationen über die Befehlszeile skripten oder ausführen möchten. Verwenden Sie das Portal, wenn Sie eine geführte Erfahrung für die Auswahl von Repositorys, das Starten von Migrationen und das Nachverfolgen des Fortschritts benötigen.

Kernfunktionen

ELM bietet die folgenden Kernfunktionen:

• Kontinuierliche Synchronisierung: ELM synchronisiert Änderungen aus Azure DevOps mithilfe inkrementeller Synchronisierung und Delta-Nachverfolgung nach GitHub, sodass Teams bis zur Umstellung in Azure DevOps weiterarbeiten können. Planen Sie bei der Umstellung ein kurzes schreibgeschütztes Zeitfenster ein – in der Regel für die meisten Repositorys weniger als 30 Minuten.
• Migrationen mit mehreren Repositorys: ELM unterstützt die Migration mehrerer Repositorys mit bis zu 20 gleichzeitigen Migrationsaufträgen. Führen Sie in der CLI den Migrationsbefehl für jedes Repository einzeln aus. Auf der Benutzeroberfläche können Sie bis zu 20 Repositorys auswählen, die zusammen migriert werden sollen.
• Migrationsworkflow von Anfang bis Ende: ELM verfolgt die Repository-Zustände über Initialisierung, Synchronisierung, Umschaltung, Validierung und Abschluss hinweg. Dieses Modell bietet Ihnen Einblicke in den Migrationsfortschritt und unterstützt die Problembehandlung.
• Vom Kunden geplante Umstellung: Sie legen den Zeitpunkt für die Umstellung fest und planen sie, um das Datensatzsystem von Azure DevOps auf GitHub umzustellen.
• Einfachere Einrichtung nach der Migration: ELM trägt dazu bei, den manuellen Aufwand nach dem Cutover zu reduzieren, indem die Azure-Boards-Verbindung eingerichtet und Azure Pipelines so neu konfiguriert werden, dass sie auf das migrierte GitHub-Repository verweisen. Dadurch wird es für Teams einfacher, Azure DevOps weiterhin für die Planung und Pipelines zu nutzen, während sie GitHub für den Quellcode verwenden – mit weniger Reibungsverlusten bei Übergaben und weniger Nacharbeiten.

Migrationsdatenfluss

ELM überträgt Repositorydaten von der Quelle an GitHub Enterprise Cloud über verschlüsselte Kanäle. Es migriert Repositoryinhalte, Verlauf, Metadaten und Berechtigungen und verwendet dann die inkrementelle Synchronisierung, um nur Änderungen nach der ersten Übertragung zu kopieren. ELM speichert keine Kunden-Repositoryinhalte außerhalb des Migrationsprozesses.

Sicherheit und Datenverarbeitung

ELM ist so konzipiert, dass Ihre Repositoryinhalte unter Ihrer Kontrolle bleiben und Microsoft nur die minimalen betriebstechnischen Daten aufbewahrt, die für die Ausführung der Migration erforderlich sind.

Daten im Transit

Die gesamte Kommunikation zwischen Azure DevOps, dem selbst gehosteten Linux-Agent und GitHub Enterprise Cloud verwendet TLS-verschlüsseltes HTTPS. Repositoryinhalte werden über verschlüsselte Git-Protokolle übertragen. ELM speichert keine Kunden-Repositoryinhalte außerhalb des aktiven Migrationsprozesses.

Umgang mit PAT

ELM erfordert zwei GitHub persönliche Zugriffstoken (PERSONAL Access Tokens, PATs), die jeweils für einen anderen Zweck verwendet werden. Behandeln Sie beide als vertraulich und gewähren Sie nur die in den Voraussetzungen dokumentierten Bereiche. Legen Sie für beide PATs kurze Ablaufzeiten fest und rotieren oder ziehen Sie sie nach Abschluss der Migration zurück. Widerrufen Sie beide PAT sofort, wenn Sie die Exposition vermuten. Beschränken Sie, wer die Dienstverbindung mit dem Migrationsoperator und den erforderlichen Administratoren anzeigen oder bearbeiten kann.

• Dienstverbindung PAT: Ein GitHub Enterprise-Administrator erstellt diesen PAT und verwendet ihn, um die Azure DevOps Dienstverbindung für das Ziel GitHub Organisation zu erstellen. Speichern Sie diesen PAT nur in der Dienstverbindung. Übertragen Sie es nicht in die Versionsverwaltung, teilen Sie es nicht im Chat und fügen Sie es nicht in Protokolle ein.
• Persönliche Migration PAT: Die Person, die die Migration durchführt, erstellt diesen PAT und verwendet diese, um sich während der Migration bei GitHub zu authentifizieren.

Was Microsoft aufbewahrt

ELM speichert nur Betriebsmetadaten zu Ihrer Migration – Repository-IDs, Migrationsstatus, Validierungsergebnisse, Fehlermeldungen und Überwachungsereignisse. ELM behält Ihre Repositoryinhalte, commit-Daten oder PAT nach Abschluss der Migration nicht bei.

Überwachung

ELM protokolliert Ereignisse im Migrationslebenszyklus im Azure DevOps-Überwachungsprotokoll, sodass Unternehmensadministratoren überprüfen können, wer eine Migration gestartet, angehalten, fortgesetzt, den Cutover dafür geplant oder abgebrochen hat. Verwenden Sie das Überwachungsprotokoll, um Complianceüberprüfungen zu unterstützen und die Migrationszeitachse zu rekonstruieren, wenn Sie ein Problem untersuchen müssen.

Um Überwachungsereignisse anzuzeigen, wechseln Sie zurÜberwachung der >, und filtern Sie nach dem Bereich "Enterprise Live-Migrationen".

Umfang der ELM

Was ELM automatisiert

• Führt Überprüfungen vor der Migration aus.
• Synchronisiert Git-Code, einschließlich Verzweigungen, Änderungsverlauf und Tags mit GitHub.
• Synchronisiert Pullanforderungen, einschließlich Titeln, Beschreibungen, Kommentaren und Benutzerverlauf.
• Erstellt das Ziel-GitHub Repository.
• Migriert Branchrichtlinien in GitHub-Branch-Regelsätze.
• Konfiguriert Azure Pipelines so um, dass das neue GitHub-Repository verwendet wird.
• Erstellt eine Boards-Verbindung.
• Wechselt von Azure DevOps zu GitHub.

Was Sie manuell tun

• Bereinigen Sie das Azure DevOps Repository vor der Migration (große Dateien, Pullanforderungen mit 10.000 Dateien und langen Referenznamen).
• Erstellen Sie die Ziel-GitHub-Organisation.
• Überprüfen Sie den Zustand des Repositorys nach der Migration (Branches, Tags, Verlauf, Pull Requests).
• Migrierte Branch-Regelsätze überprüfen und anpassen.
• Aktualisieren Sie hartcodierte Azure DevOps Repository-URLs in Skripts, Pipelines und Tools.
• Richten Sie den Team- und Benutzerzugriff in GitHub ein.
• Migrieren oder stilllegen Sie Arbeitselemente, Wikis, Pipelines und andere Daten außerhalb von Repositorys.

Was von ELM migriert wird

Migrierte Daten

ELM migriert derzeit die folgenden Repositorydaten von Azure DevOps Services zu GitHub Enterprise Cloud mit Data Residency:

• Git-Quellcode, einschließlich des vollständigen Commitverlaufs
• Verzweigungen und Tags
• Verzweigungsrichtlinien, als GitHub-Verzweigungsregelsätze migriert
• Pull-Request-Metadaten, einschließlich der Titel, Beschreibungen, Quell- und Ziel-Branches sowie Kommentare
• Benutzerverlauf für Pull Requests

Nicht migrierte Daten

ELM migriert die folgenden Daten nicht:

• Arbeitsaufgaben
• Pipelinedefinitionen
• Veröffentlichungen
• Wikis
• Testpläne und Testergebnisse
• Azure Artifacts
• Git LFS-Objekte (Zukunft)

ELM migriert aktive und gemergte Pull Requests sowie Pull Requests mit verfügbarem Branchverlauf. Verwaiste Pull Requests mit gelöschten Branches werden nicht migriert.

Wie ELM Pipelines verwendet und was für Kosten zu erwarten ist

ELM wird in Azure Pipelines mithilfe eines selbst gehosteten Linux-Agents ausgeführt. Während einer Migration verwendet ELM zwei Arten von Aufträgen:

• Bei der ersten Überprüfung wird überprüft, ob das Repository für die Migration bereit ist. Diese Aufgabe wird nur einmal ausgeführt.
• Sync kopiert das Repository nach GitHub und synchronisiert Änderungen bis zur Umstellung weiter.

Ihr selbst gehosteter Linux-Agent muss online bleiben und für die Dauer der Migration verfügbar sein.

Wie ELM Ihren Agent Pool verwendet

ELM minimiert die Auswirkungen auf Ihre vorhandenen Pipelines. Es verwendet jeweils nur einen Agent, unabhängig davon, wie viele Agents sich im Pool befinden. Für jedes Repository führt ELM jeweils einen Auftrag in die Warteschlange ein, führt keine Aufträge parallel aus und wartet in der Regel 30 bis 60 Minuten, bevor der nächste Auftrag in die Warteschlange gestellt wird, damit andere Pipelinearbeiten fortgesetzt werden können.

In der Praxis verhält sich ELM wie jeder andere Pipeline-Einzelvorgang und nutzt dieselben Kapazitäten wie Ihre aktuellen Builds. Es sollte nicht den gesamten Pool belegen oder nicht verwandte Aufgaben blockieren.

Was für Kosten zu erwarten ist

ELM selbst ist kostenlos zu verwenden. Ihre einzigen potenziellen Kosten entstehen durch die Azure-Pipelines-Kapazität, wenn Ihre Organisation das enthaltene Kontingent für parallele Aufträge überschreitet.

Jeder ELM-Auftrag kann bis zu einer Stunde ausgeführt werden, aber Azure Pipelines Abrechnung basiert auf paralleler Auftragskapazität, nicht auf der Anzahl der verwendeten Agents oder Minuten. Da SICH ELM auf einen gleichzeitigen Auftrag beschränkt, können viele Kunden Migrationen innerhalb ihrer vorhandenen Kapazität ohne zusätzliche Kosten ausführen. Wenn Sie die enthaltene Kapazität überschreiten, müssen Sie möglicherweise zusätzliche parallele Aufträge erwerben. Azure Pipelines beinhaltet auch kostenlose Minuten für private Projekte, daher gelten die Zusatzkosten in der Regel nur, nachdem die kostenlose Stufe erschöpft ist.

Workflow bei der Migration

Auf hoher Ebene folgt eine ELM-Migration diesen Schritten. Jeder Schritt enthält Links zu detaillierten Anweisungen.

1. Erfahren Sie mehr über Enterprise Live-Migrationen. Lesen Sie diese Übersicht, um zu verstehen, was ELM tut, was migriert wird und wie es in Ihren Migrationsplan passt. Entscheiden Sie, ob Ihr Team Entwicklungsworkflows vollständig zu GitHub verlagern oder Azure DevOps und GitHub weiterhin gemeinsam in einem Hybridmodell verwenden möchte. Wenn Sie ein Hybridmodell auswählen, kann ELM dabei helfen, den Einrichtungsaufwand nach der Migration zu verringern, indem es Azure Pipelines mit dem migrierten GitHub-Repository neu verbindet und die Azure-Boards-Verbindung erstellt.
2. Vollständige Voraussetzungen. Überprüfen Sie den Zugriff, die Tools und die Authentifizierung, und erfassen Sie die IDs, die Sie zum Ausführen von Migrationsbefehlen benötigen. Weitere Informationen finden Sie unter "Vollständige Voraussetzungen".
3. Starten Sie die Migration. Authentifizieren Sie sich bei Azure DevOps, legen Sie Ihre Standardwerte fest, und verwenden Sie die ELM CLI, um die anfängliche Synchronisierung zu starten. Weitere Informationen finden Sie unter Starten der Migration.
4. Überwachen der Migration Überwachen Sie die Erstsynchronisierung und die nachfolgenden inkrementellen Synchronisierungen. Weitere Informationen finden Sie unter Überwachen der Migration.
5. Wechseln Sie zu GitHub. Planen Sie die Umstellung, sobald Sie dazu bereit sind. Sie müssen die Umstellung innerhalb von 21 Tagen nach dem Start der vollständigen Migration abschließen (wenn die Erstsynchronisierung beginnt). Weitere Informationen finden Sie unter Cutover auf GitHub.
6. Ausführen von Aufgaben nach der Migration. Vergewissern Sie sich, dass alles nach Abschluss der Migration funktioniert. Weitere Informationen finden Sie unter Vollständige Aufgaben nach der Migration.

Überprüfungen vor der Migration

In der folgenden Tabelle sind die aktuellen Toolgrenzwerte aufgeführt, die während der Überprüfung überprüft wurden und was geschieht, wenn sie nicht behoben werden.

Schlüsselrollen und Zuständigkeiten

Nächster Schritt

Verwandte Inhalte

• Voraussetzungen erfüllen
• ELM CLI-Referenz