A step-by-step guide to migrating from Perforce to Git
Wie wir im letzten Artikel bereits festgestellt haben, ist Git jetzt tatsächlich die erste Wahl für SCM bei egal welcher Art digitaler Entwicklung. Doch wenn in deinen Perforce-Verläufen die Arbeit von Jahren steckt, wägst du einen Umstieg wahrscheinlich kritisch ab. In diesem Artikel gehen wir direkt auf solche Bedenken ein und erklären dir, wie du deine Daten zu Git migrieren kannst. Wir haben den Migrationsprozess von Perforce zu Git in 8 Schritte aufgedröselt:
Schritt 1: Verschieben von Perforce-Daten
Daten können im Allgemeinen auf zwei Methoden von Perforce zu Git migriert werden. Bevor wir uns jedoch damit befassen, müssen wir uns einen grundlegenden Unterschied von Perforce und Git im Umgang mit Softwareprojekten ansehen.
Ein Perforce-Server kann eine Vielzahl verschiedener Softwareprojekte enthalten, die alle über ihr eigenes Branching-Modell verfügen. Die Entwickler bestimmen die Ansicht (View), die dem Perforce-Server mitteilt, welche Dateien in einer Arbeitskopie enthalten sein sollen. Ein Git-Repository dagegen enthält normalerweise ein einziges Softwareprojekt mitsamt dessen Branches und Tags (auch wenn monolithische Git-Repos durchaus existieren). In der Regel wird das Repo geklont und ggf. werden Untermodule oder Teilbäume ausgecheckt.
Beim Verschieben der Daten solltest du dir dann zwei Fragen stellen: Wie werden die Daten von Perforce extrahiert und wie wird all das in entsprechende Git-Repositorys übertragen?
Übertragen von Perforce-Daten – Option 1: Git Fusion
Wenn du den gesamten Verlauf deiner Daten in Perforce aufbewahren möchtest, kannst du das Tool Git Fusion von Perforce zur Extrahierung eines Bereichs deines Perforce-Servers (d. h. ein einzelnes Projekt) und Übertragung in ein Git-Repo nutzen. Du führst im Wesentlichen folgende Schritte aus:
Zugehöriges Material
Verschieben eines vollständigen Git-Repositorys
Lösung anzeigen
Git kennenlernen mit Bitbucket Cloud
- Installieren von Git Fusion
- Einrichten der korrekten Ansicht deiner Daten, einschließlich deiner Branching-Struktur
- Klonen aus Git Fusion mit einem beliebigen Git-Client
- Verschieben deines Repositorys in Bitbucket
Hands-on example *In order to work through this example you’ll need a Perforce server with Git Fusion already operational.* Let’s say that you have a Perforce project living in the repository path //depot/acme/… (in Perforce depot view syntax). It has three branches: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Keep in mind that with Perforce you see branches as additional directories in the tree. Your first step is to configure Git Fusion so that it understands the branching relationship in Perforce. To do this, you create a repo configuration file: [@repo] description = Acme project charset = utf8 [main] git-branch-name = main view = //depot/acme/main/… … [r1.0] git-branch-name = r1.0 view = //depot/acme/r1.0/… … [r1.1] git-branch-name = r1.1 view = //depot/acme/r1.1/… … Submit this file to Perforce under the path //.git-fusion/repos/acme/p4gf_config Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, clone from Git Fusion: git clone https:///acme cd acme git remote add bitbucket git push –u --all bitbucket git push --tags Bitbucket That’s it! You should now see the imported history in Bitbucket.Auf diese Weise erhältst du allerdings keine 100 % genaue Kopie deiner Perforce-Daten. Für gewisse Perforce-Funktionen wie z. B. partielle Merges ist in Git kein Äquivalent vorhanden. Doch unter dem Strich wird der Großteil deines Verlaufs ohne allzu viel Aufwand beibehalten.
Denke daran, dass das Aufbewahren des Branching-Verlaufs der letzten zehn Jahre von einem alten SCM-Tool nicht bedeutet, dass du denselben Workflow beibehalten musst. Ganz im Gegenteil solltest du insbesondere einen Feature Branch Workflow wie Git-Flow als ersten praktischen Schritt in Betracht ziehen.
Vor- und Nachteile
- Ein höheres Maß an Einrichtungsarbeiten und Laufzeit erforderlich
- Sicherung eines Großteils des Verlaufs (sodass alte Perforce-Server stillgelegt werden können)
- Erhalt des alten Branching-Modells im Verlauf
Übertragen von Perforce-Daten – Option 2: Neubeginn
Alternativ kannst du dich für einen Neubeginn entscheiden. Verabschiede dich von dem alten Flickenteppich: Extrahiere nur die Spitze (den Head) von jedem Branch in Perforce, der mit deinem Projekt übereinstimmt und checke alles in ein neues leeres Git-Repository ein. (Voraussetzung hierfür ist, dass deine Perforce-Arbeitsbereiche mit einer korrekten Ansicht (View) der gewünschten Daten definiert sind.)
Dies ist die einfachste und schnellste Vorgehensweise. Egal, wie komplex dein Perforce-Verlauf war, dein neues Git-Repository ist schlank und rank. Du hast die Gelegenheit, einen neuen Git-basierten Workflow ohne Altlasten einzuführen.
Der größte Nachteil hiervon ist, dass du wahrscheinlich den alten Perforce-Server im schreibgeschützten Modus weiterlaufen lassen möchtest, falls es einmal erforderlich ist, alten Code auszugraben. Es fallen zwar keine Lizenzkosten an, aber du musst den alten Server eine Weile lang am Leben erhalten.
**Hands-on example** Go into your Perforce workspace (the directory where the main branch of your project data is checked out) and run: p4 sync This fetches the latest revision of your files. Now create an empty project called acme in Bitbucket using the normal Bitbucket administration tools. You can configure the access control and team members per your usual standards. Next, create a new Git repo in your workspace and push to Bitbucket: git init . git remote add origin git push –u --all origin git push --tags origin You should now see the latest snapshot of your code as the first commit in your new Bitbucket project.Vor- und Nachteile
- Schnell und einfach
- Neukonzipierung des Branching-Modells und Workflows
- Älterer Perforce-Server für schreibgeschützten Zugriff
Schritt 2: Benutzer und Zugriffsrechte
Nach dem Verschieben der Daten solltest du als Nächstes Benutzer und Zugriffsrechte für die neuen Bitbucket-Projekte zuweisen. Mit LDAP für den Zugriff auf Benutzerverzeichnisse kannst du dabei etwas Zeit einsparen. Du kannst aber auch ganz einfach Benutzerkontensätze von Perforce mit dem p4-Befehl "user -o" extrahieren und dann einen Kontensatz pro Projekt in Bitbucket eingeben.
Es kann schwierig sein, Perforce-Zugriffsrechte zu entsprechenden Bitbucket-Zugriffsrechten zu übertragen, denn Zugriffsrechte in Perforce sind granular und komplex und ermöglichen das Ausschließen von Zugriffsrechten auf einzelne Dateien. Dieses komplizierte Zugriffsrechtmuster ist einer der Gründe, weshalb ein Perforce-Server ins Stocken geraten kann. Bei jedem Zugriffsversuch muss der Server aufwendige Berechnungen zu komplexen Datenstrukturen durchführen.
Schneller geht es in den meisten Fällen, wenn die Projektleiter einfachere Zugriffsrechte in Bitbucket auf Projekt-, Repository- und Branch-Ebene definieren. Da Git so viele neue Workflow-Optionen bietet, solltest du ohnehin deine Berechtigungseinstellungen neu definieren. In Perforce kann z. B. die Branch-Erstellung beschränkt sein, während in Bitbucket nur der Push-Zugriff auf den Main-Branch beschränkt werden muss.
Schritt 3: Binärdateien
Wenn du in Perforce große Binärdateien gespeichert hast, solltest du über die Verwaltung dieser Ressourcen in Git nachdenken. Du kannst Git LFS ausprobieren, oder stattdessen einfach ein normales Verwaltungssystem für Artefakte verwenden. Egal, für welche Lösung du dich entscheidest, solltest du große Dateien nicht einfach blindlings in ein Git-Repository verschieben.
Schritt 4: Komplexe Abhängigkeiten
A Perforce working copy may actually map in read-only copies of data from several modules. In Git, this is done either using submodules, subtrees, or by leveraging CI/CD or artifact management systems. There’s no easy answer here, but some data import tools can model a submodule relationship between Git repos. For a more in depth look on how to use submodules or subtrees, you can read about each here: https://www.atlassian.com/git/tutorials/git-subtree.
Schritt 5: Strukturierung deines Teams während der Migration
Auf deinem Perforce-Server befinden sich jetzt 100 Projekte von 10 Teams. Deine Migrationsstrategie ist ausgearbeitet und deine Tools stehen bereit. Plane dein Wartungszeitfenster und schon kann es losgehen!
Hm … nein.
Vergiss nicht, dass es beim Umstieg auf ein anderes SCM-Tool nicht nur um die Entwickler geht, sondern auch um Daten. Du musst das Team, den Prozess und auch Abläufe berücksichtigen. Versuche also besser nicht, zu viel auf einmal unter einen Hut zu bringen. Das Risiko ist einfach zu hoch.
Während der Migration solltest du dir über den Projektplan Gedanken machen. (Das wäre ein günstiger Zeitpunkt, um einen neuen Jira-Workflow auszuprobieren …) Folgende Optionen sind vielleicht für dich interessant.
- Migriere jedes Team und Projekt einzeln. Versuche, mit der Migration eines Teams oder Projekts am Anfang eines Sprints oder einer Programmetappe zu beginnen, damit du ein wenig Zeit zur Eingewöhnung hast.
- Migriere inkrementell. Importiere alle deine Daten an einem Wochenende, aber gib deinen Teams Zeit, langsam zu Git überzugehen. Übertrage in regelmäßigen Abständen die Deltas, indem du deine Importtools erneut ausführst. Diese Strategie ist zwar etwas komplexer, aber nicht schlecht, wenn Abhängigkeiten zwischen Teams bestehen, und die Teams, die zuerst gewechselt haben, benötigen mindestens einen aktuellen Snapshot in Git, um ihre CI/CD-Pipeline am Laufen zu halten.
- Verwende eine Zeit lang beide Systeme parallel. Diese Methode mag sich für Zartbesaitete eher nicht eignen, aber theoretisch ist ein wechselseitiger Datenaustausch mit Git Fusion möglich, solange du keine komplexen Operationen ausführst, die der Datenübersetzer nicht bewältigen kann.
Nimm dir am Schluss etwas Zeit, um dem Team die Änderungen mitzuteilen. Nenne Anregungen und Gründe und erkläre einige Schritte zur Umsetzung. Stelle ein "Erstanwender"-Team aus Entwicklern zusammen, die am gesamten Softwareentwicklungszyklus beteiligt und den anderen ein Beispiel sind. Suche Git-Profis, die anderen bei Problemen helfen können. Mit kleinen, gut nachvollziehbaren und iterativen Änderungen kannst du diesen Prozess erfolgreich umsetzen.
Step 6: Mirrors and clusters
Perforce verfügt über ein einfaches, aber effektives System zum Spiegeln von Daten für Remote-Standorte, um die Auswirkungen der Latenz zu umgehen. Darüber hinaus ist noch ein komplexeres System zum Ausführen von Mirrors für schreibgeschützte Cluster vorhanden. Auch wenn Latenz bei Git kein allzu großes Thema ist, solltest du bei einem weltweiten Betrieb für das Clustering und Mirroring trotzdem Bitbucket Data Center in Betracht ziehen. Diese Lösung beschleunigt die Dauer des Klonens in globalen Teams erheblich.
Step 7: ALM tools
Und nun etwas wirklich Tolles: Wenn du von Perforce zu Git umsteigst, hast du die große Wahl, was deine ALM-Tools betrifft. So ziemlich jeder Entwickler arbeitet mit Git – und so ziemlich jedes ALM-Tool funktioniert mit Git. Natürlich ist auch die Integration von Bitbucket in Jira und Bamboo hervorragend. Bei der Migration zu Git kannst du dir Bamboo-Features wie Plan-Branches und damit die Vorteile eines Feature Branch Workflows zunutze machen.
Schritt 8: Definieren einer erfolgreichen Migration
Wie genau bewertest du den Erfolg einer Migration von Perforce zu Git? In vielen Migrationsprojekten konzentrieren wir uns zu sehr auf die Genauigkeit des Datentransfers. Das ist jedoch aus verschiedenen Gründen keine besonders nützliche Metrik. Sehr wahrscheinlich wirst du in Git nicht exakt denselben Verlauf erhalten, der in einem zentralisierten SCM-System wie Perforce vorhanden war.
Zur Überprüfung ist ein CI/CD-Ansatz besser geeignet. Sind deine Tests auch noch erfolgreich, nachdem deine CI/CD-Pipeline von Perforce zu Git gewechselt ist? Und bist du immer noch in der Lage, deine Software zu deployen? Wenn auch alle deine wichtigen älteren Builds weiterhin die CI/CD-Pipeline passieren können, hast du erfolgreich das Ziel erreicht.
Fertig!
Wir haben gesehen, was zwischen Perforce und Git passiert und wie die Migration tatsächlich abläuft. Der nächste Schritt ist die Wahl einer Git-Lösung. Wenn du von Perforce wechselst und Spiele entwickelst, kannst du hier erfahren, warum Spielentwickler Bitbucket so schätzen.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
Bitbucket-Blog
DevOps-Lernpfad
