Migration overview (Übersicht über die Migration)

Der Wechsel von Azure DevOps Server zu Azure DevOps Services ist ein wesentlicher Schritt für Organisationen, die cloudbasierte Zusammenarbeit, Skalierbarkeit und erweiterte Features nutzen möchten. In dieser Übersicht untersuchen wir die Optionen zum Übertragen Ihrer wertvollen Daten vom lokalen Azure DevOps Server in die cloudbasierten Azure DevOps Services.

Informationen zu den Hauptunterschieden zwischen dem lokalen Azure DevOps-Server und den cloudbasierten Azure DevOps Services finden Sie unter Vergleich von Azure DevOps Services mit Azure DevOps Server – Azure DevOps.

Unabhängig von Der ausgewählten Migrationsoption wird empfohlen, Ihre wichtigsten Ressourcen wie Quellcode und Arbeitsaufgaben zu ermitteln. Sie sollten sich ihre Datengröße, organisationsweite Komplexität überlegen und sicherstellen, dass Sie genügend Zeit für Testläufe haben, bevor die tatsächliche Migration für einen reibungslosen und erfolgreichen Übergang erfolgt.

Migrationsansätze

Es ist wichtig, die Vor- und Nachteile jedes Migrationsansatzes zu bewerten, basierend auf Ihren spezifischen Motivationen für die Einführung von Azure DevOps Services. Die richtige Strategie hängt von Ihrem einzigartigen Kontext und Ihren Anforderungen ab.

Option 1: Manuelle Migration

Wenn sich beispielsweise das Azure DevOps-Team bei Microsoft entschieden hat, von Azure DevOps Server zu Azure DevOps Services zu wechseln, haben wir uns auch entschieden, von Team Foundation-Versionskontrolle (TFVC) zu Git zu wechseln. Die Migration erforderte eine menge Planung, aber wenn wir migriert haben, haben wir ein neues Git-Repository mit der "Tipp"-Version unserer TFVC-Quellen erstellt und unsere Geschichte in Azure DevOps Server hinter sich gelassen. Wir haben auch unsere aktiven Arbeitsaufgaben verschoben und alle alten Fehler hinter sich gelassen, Benutzergeschichten und Aufgaben abgeschlossen usw.

Manueller Migrationsprozess

1. Identifizieren Sie die wichtigsten Ressourcen, die Sie migrieren müssen – in der Regel Quellcode, Arbeitsaufgaben oder beides. Andere Ressourcen in Azure DevOps Server – Erstellen von Pipelines, Testplänen usw. – sind schwieriger, manuell zu migrieren.
2. Identifizieren Sie einen geeigneten Zeitpunkt, um den Übergang vorzunehmen.
3. Bereiten Sie Ihre Zielorganisationen vor. Erstellen Sie die Organisationen und Teamprojekte, die Sie benötigen, Bereitstellen von Benutzern usw.
4. Migrieren Sie Ihre Daten.
5. Erwägen Sie, die Azure DevOps Server-Quellbereitstellungen schreibgeschützt zu machen. Dies ist auf folgende Weise möglich:
   • Anpassen von Berechtigungen auf Projektebene: Legen Sie die Berechtigungen für alle Benutzer oder Gruppen auf Projektebene auf schreibgeschützt fest, was Sie tun können, indem Sie die Sicherheitsrollen in den Project-Einstellungen ändern.
   • Ändern von Repositoryeinstellungen: Für jedes Repository können Sie die Einstellungen ändern, um sie schreibgeschützt zu machen, was das Anpassen der Berechtigungen für jeden Benutzer oder jede Gruppe umfasst, um nur Leseaktionen zuzulassen.
   • Verwenden Sie integrierte Sicherheitsgruppen: Verwenden Sie die integrierten Sicherheitsgruppen, um Berechtigungen effizienter zu verwalten. Sie können Benutzern Gruppen wie "Leser" zuweisen, um schreibgeschützten Zugriff zu ermöglichen.
   • Skripterstellungsberechtigungsänderungen: Wenn Sie über viele Projekte oder Repositorys verfügen, müssen Sie diese möglicherweise skripten. Sie können die Azure CLI DevOps-Erweiterung verwenden, um alle Berechtigungen aufzulisten und nach Bedarf zu aktualisieren.
   • Repositoryfeature deaktivieren: Deaktiviert den Zugriff auf das Repository, einschließlich Builds und Pullanforderungen, hält das Repository jedoch mit einer Warnung auffindbar. Wechseln Sie zu Project-Einstellungsrepositorys>>, und verschieben Sie neben "Repository deaktivieren" den Umschalter auf "Ein".

Option 2: Azure DevOps Data Migration Tool

Das Azure DevOps-Datenmigrationstool ist eine Reihe von Dienstprogrammen, die von Microsoft bereitgestellt werden, um die Migration von Daten von Azure DevOps Server zu Azure DevOps Services zu erleichtern. Diese Tools bieten einen optimierten Ansatz zum Migrieren verschiedener Artefakte, darunter Quellcode, Arbeitsaufgaben, Testfälle und andere projektbezogene Daten.

Bevor Sie den Migrationsprozess initiieren, können die Tools eine Vormigrationsanalyse durchführen, um die Bereitschaft der Quellumgebung zu bewerten und potenzielle Probleme oder Abhängigkeiten zu identifizieren, die sich auf die Migration auswirken könnten. Bewerten Sie die Bereitschaft, damit Sie potenzielle Herausforderungen vorher planen und mindern können.

Einschränkungen des Migrationstools

Mit dem Tool können Sie eine Azure DevOps Server-Sammlung in eine neue Azure DevOps Service-Organisation "heben und verschieben", ohne änderungen aus den folgenden Gründen:

• Datenintegrität und Konsistenz:
  • Beim Migrieren von Daten ist die Aufrechterhaltung der Integrität und Konsistenz von entscheidender Bedeutung. Das Zulassen von Änderungen während der Migration kann zu Datenbeschädigungen oder Inkonsistenzen führen.
  • Das Tool stellt sicher, dass Die Daten während des Übertragungsprozesses erhalten bleiben, wodurch das Risiko von Fehlern minimiert wird.
• Erhaltung der Quelldaten:
  • Das Migrationstool zielt darauf ab, die Quelldaten in der Zielumgebung getreu zu replizieren.
  • Änderungen können die ursprünglichen Daten ändern, wodurch möglicherweise Diskrepanzen zwischen den migrierten Daten und den Quelldaten verursacht werden.
• Vorhersehbares Verhalten:
  • Durch das Einschränken von Änderungen stellt das Tool während der Migration ein vorhersagbares Verhalten sicher.
  • Benutzer können sich auf konsistente Ergebnisse ohne unerwartete Änderungen verlassen.
• Migrationsfokus, keine Transformation:
  • Der Hauptzweck des Migrationstools besteht darin, Daten von einem Speicherort an einen anderen zu verschieben.
  • Die Datentransformation (z. B. das Ändern von Werten) wird normalerweise nach der Migration separat behandelt.

Sie können Daten löschen, die Sie vor oder nach der Migration nicht benötigen.

Migrationstoolprozess

1. Schließen Sie die Voraussetzungen ab, z. B. das Aktualisieren von Azure DevOps Server auf eine der beiden neuesten Versionen.
2. Überprüfen Sie jede Sammlung, die Sie zu Azure DevOps Services verschieben möchten.
3. Generieren Sie Migrationsdateien.
4. Bereiten Sie alles für ihre Migrationsausführung vor.
5. Führen Sie eine Testausführung aus.
6. Durchführen einer Migration.
7. Vergewissern Sie sich, dass Ihre Benutzer und Daten migriert wurden und die Sammlung wie erwartet funktioniert.

Option 3: API-basierte Migration

Wenn Sie das Datenmigrationstool aus irgendeinem Grund nicht verwenden können, aber dennoch eine höhere Genauigkeit als Option 2 wünschen, können Sie aus verschiedenen Tools auswählen, die öffentliche APIs zum Verschieben von Daten verwenden.

API-basierte Migrationsbeschränkungen

Die folgenden Einschränkungen treten bei apibasierter Migration auf:

• Migration mit geringer Genauigkeit:
  • Einschränkung: API-basierte Tools bieten eine höhere Genauigkeit als manuelles Kopieren, sind aber immer noch relativ niedrig.
  • Implication: Obwohl diese Tools eine gewisse Genauigkeit bieten, behalten sie nicht alle Aspekte Ihrer Daten bei.
    • Beispiel: Keine davon behält die ursprünglichen Datumsangaben von TFVC-Änderungen (Team Foundation-Versionskontrolle).
    • Viele behalten auch die geänderten Datumsangaben von Überarbeitungen von Arbeitsaufgaben nicht bei.
• Datenverlust und ID-Änderungen:
  • Einschränkung: Während der Migration werden die Änderungen an Arbeitsaufgaben, TFVC-Änderungen, Paketfeeds und Pipelineartefakten wiedergegeben.
  • Auswirkung: Dieser Prozess kann zu Datenverlust führen, neue IDs generieren und Erstellungs-, Änderungs- und Schließungsdaten ändern.
    • Beispiel: Historischer Kontext, der an bestimmte Datumsangaben gebunden ist, kann verloren gehen, was die Berichterstellung und Rückverfolgbarkeit beeinflusst.

API-basierter Migrationsprozess

Im Allgemeinen empfehlen wir diesen Ansatz nur, wenn eine zusätzliche Genauigkeit über eine manuelle Kopie hinaus wichtig ist. Wenn Sie sich für diesen Ansatz entscheiden, können Sie einen Berater einstellen, der Erfahrung mit einem oder mehreren tools hat, und eine Testmigration vor der endgültigen Migration durchführen.

Viele Organisationen benötigen eine sehr präzise Migration nur für eine Teilmenge ihrer Arbeit. Neue Arbeiten könnten potenziell direkt in Azure DevOps Services beginnen. Andere Arbeiten mit weniger strengen Genauigkeitsanforderungen könnten mithilfe eines der anderen Ansätze migriert werden.

Unterstützte Prozessmodelle

Azure DevOps Services unterstützt die folgenden Prozessmodelle:

• Geerbt
• Gehostete XML

Standardmäßig ist gehostetes XML in Azure DevOps Services deaktiviert. Wir aktivieren das Gehostete XML-Prozessmodell während der Migration nur, wenn Sie ein Projekt in Azure DevOps Server angepasst haben. Sobald sich Ihr Projekt auf gehosteter XML befindet, können Sie es nach der Migration aktualisieren, um es geerbt zu haben.

Wichtige Grundsätze

Beachten Sie bei der Migration zu Azure DevOps Services die folgenden wichtigen Prinzipien und Einschränkungen:

• Azure DevOps Services ist nur englisch: Azure DevOps Server unterstützt mehrere Sprachen, aber heute unterstützt Azure DevOps Services nur Englisch. Wenn Ihre Sammlung die Nicht-Englisch-Sprache verwendet oder in der Vergangenheit nicht englisch verwendet wird und Sie die Sprache während eines Upgrades in Englisch konvertiert haben, können Sie das Datenmigrationstool nicht verwenden.
• Vererbung: Ein Projekt, das aus der Agile-, Scrum- oder CMMI-Prozessvorlage erstellt und nie angepasst wurde, befindet sich nach der Migration auf dem Vererbungsprozessmodell.
• Gehostetes XML: Jedes Projekt mit Anpassungen verwendet das Gehostete XML-Prozessmodell.
• Prozess pro angepasstem Projekt: Obwohl Azure DevOps Services es Projekten ermöglicht, einen Prozess freizugeben, erstellt das Datenmigrationstool für jedes angepasste Teamprojekt einen gehosteten XML-Prozess. Wenn Sie beispielsweise über 30 angepasste Projekte verfügen, verfügen Sie über 30 gehostete XML-Prozesse, die verwaltet werden sollen. Wenn Sie Ihren gehosteten XML-Prozess für alle Ihre Projekte weiter anpassen möchten, müssen Sie jeden gehosteten XML-Prozess separat aktualisieren.
• Prozessüberprüfung: Die Prozessüberprüfung des Datenmigrationstools erkennt das Zielprozessmodell für jedes Projekt. Bevor Sie migrieren können, müssen Sie alle Prozessüberprüfungsfehler für die gehosteten XML-Projekte beheben. Möglicherweise sollten Sie die Aktualisierung des Prozesses Ihrer Projekte in Betracht ziehen, um einem unserer Prozesse (Agile, Scrum oder CMMI) zu entsprechen, um das Vererbungsprozessmodell zu nutzen. Erfahren Sie mehr über die Prozessvalidierungstypen in unserer Dokumentation.

Ressourcen

• Melden eines Problems im Entwicklercommunity
• Support erhalten und Feedback geben

Nächste Schritte

Verwandte Artikel

• Vollständige Voraussetzungen für die Migration
• Überprüfen und Vorbereiten der Migration
• Vorbereiten der Testausführung
• Ausführen der Testausführungsmigration
• Migrieren zu Azure DevOps Services
• Ausführen von Aufgaben nach der Migration