Ein detaillierter Leitfaden für die Migration von Perforce zu 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:

• Verschieben von Perforce-Daten
• Benutzer und Zugriffsrechte für ein neues Git-Repository zuweisen
• Große Binärdateien
• Komplexe Abhängigkeiten
• Strukturierung deines Teams während der Migration
• Spiegeln von Daten
• ALM-Tools
• Wann kann eine Migration von Perforce zu Git als erfolgreich angesehen werden?

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:

• 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

 Ein praktisches Beispiel *Um dieses Beispiel durchzuarbeiten, benötigst du einen Perforce-Server, auf dem Git Fusion bereits betriebsbereit ist.* Nehmen wir an, du hast ein Perforce-Projekt unter dem Repository-Pfad //depot/acme/… (in Perforce-Depotansichtssyntax). Dieses verfügt über drei Branches: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Denke daran, dass dir Branches in Perforce als zusätzliche Verzeichnisse im Strukturbaum angezeigt werden. Als Erstes konfigurierst du Git Fusion, sodass die Branching-Beziehungen in Perforce erfasst sind. Hierfür erstellst du eine Repository-Konfigurationsdatei: [@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/… … Übermittle diese Datei an Perforce unter dem Pfad //.git-fusion/repos/acme/p4gf_config Erstelle nun in Bitbucket mit den normalen Bitbucket-Administrationstools ein leeres Projekt namens acme. Die Zugriffskontrolle und Teammitglieder kannst du entsprechend deinen üblichen Standards konfigurieren. Als Nächstes klonst du von Git Fusion: git clone https:///acme cd acme git remote add bitbucket  git push –u --all bitbucket git push --tags Bitbucket Das war's! Jetzt solltest du den importierten Verlauf in Bitbucket sehen.

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.

 **Ein praktisches Beispiel** Rufe deinen Perforce-Arbeitsbereich auf (das Verzeichnis, aus dem der Main-Branch deiner Projektdaten ausgecheckt wird) und führe Folgendes aus: p4 sync Hiermit wird die neueste Überarbeitung deiner Dateien abgerufen. Erstelle nun in Bitbucket mit den normalen Bitbucket-Administrationstools ein leeres Projekt namens acme. Die Zugriffskontrolle und Teammitglieder kannst du entsprechend deinen üblichen Standards konfigurieren. Erstelle als Nächstes in deinem Arbeitsbereich ein neues Git-Repository und übertrage es zu Bitbucket: git init .git remote add origin  git push –u --all origin git push --tags origin Jetzt solltest du den neuesten Snapshot deines Codes als ersten Commit in deinem neuen Bitbucket-Projekt sehen.

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

Eine Perforce-Arbeitskopie kann auf schreibgeschützte Kopien von Daten aus verschiedenen Modulen verweisen. In Git geschieht das entweder mithilfe von Untermodulen, Unterbäumen (subtrees), CI/CD oder Artefaktmanagementsystemen. Das lässt sich schwer in einem Satz erklären. Soviel sei gesagt: Einige Tools zum Datenimport sind in der Lage, Untermodulbeziehungen zwischen Git-Repositorys herzustellen. Wenn du mehr über Untermodule und Unterbäume erfahren willst, lies diesen Post: https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-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.

Schritt 6: Mirror und Cluster

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.

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