A step-by-step guide to migrating from Perforce to Git

Stap 2: Gebruikers en rechten

Nadat de gegevens zijn verplaatst, moet je gewoonlijk beginnen met het koppelen van je gebruikers en rechten aan nieuwe Bitbucket-projecten. Als je LDAP voor een gebruikerslijst gebruikt, bespaar je hier wat tijd. Anders kun je eenvoudig een set gebruikersaccounts uit Perforce extraheren met de opdracht p4 users -o en ze vervolgens per project in Bitbucket invoeren.

Het vertalen van Perforce-rechten naar vergelijkbare Bitbucket-rechten kan moeilijk zijn omdat Perforce-rechten granulair en complex zijn en de mogelijkheid bieden om toegang tot individuele bestanden uit te sluiten. Dit ingewikkelde rechtenschema is een van de redenen waarom een Perforce-server kan vastlopen: elke poging tot toegang kan ertoe leiden dat de server een dure berekening uitvoert op een ingewikkelde gegevensstructuur.

In de meeste gevallen is het sneller om projectleiders te vragen om een eenvoudigere set rechten in Bitbucket te definiëren met behulp van de normale rechten op project-, repo- en branchniveau. Je zult hoe dan ook nog eens naar je instellingen voor rechten moeten kijken, want Git biedt zoveel nieuwe workflowopties. In Perforce kun je bijvoorbeeld beperkte branches aanmaken, terwijl je in Bitbucket misschien alleen de push-toegang tot de main-branch hoeft te beperken.

Stap 3: Binaire bestanden

Als je grote binaire blobs in Perforce hebt opgeslagen, moet je goed nadenken over hoe je die in Git wilt beheren. Je zou Git LFS kunnen uitproberen, of in plaats daarvan gewoon een normaal systeem voor het beheer van artefacten gebruiken. In ieder geval wil je niet blindelings grote blobs naar een Git-repo pushen.

Stap 4: Complexe afhankelijkheden

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.

Stap 5: Je team structureren tijdens de migratie

Dus je Perforce-server heeft 100 projecten van 10 teams. Je hebt een migratiestrategie en tools. Plan de onderhoudsbeurt en ga aan de slag!

Was het maar zo simpel …

Het overstappen naar SCM-tools draait net zo goed om ontwikkelaars als om gegevens. Je moet rekening houden met mensen, processen en een planning. Ga dus niet over één nacht ijs. Dat is te riskant.

Tijdens de eigenlijke migratiefase moet je een projectplan overwegen. (Het is misschien een goed moment om een nieuwe Jira-workflow uit te proberen …) Hier zijn enkele opties die je kunt bekijken.

• Migreer per team en per project. Streef ernaar om een project en team aan het begin van een sprint of programmastap te starten, wanneer de tijdsdruk niet te hoog is;
• Migreer stapsgewijs. Importeer al je gegevens in een weekend, maar laat de teams daarna langzaam de overstap naar Git voltooien. Haal regelmatig de delta's op door je importtools opnieuw uit te voeren. Deze strategie is weliswaar complexer, maar niet slecht als je afhankelijk bent van teams en de early adopters op zijn minst een recente momentopname in Git nodig hebben om hun CI/CD-pipeline te voeden;
• Gebruik beide systemen een bepaalde tijd naast elkaar. Deze methode is niet bedoeld voor bangeriken, maar het is technisch mogelijk om Git Fusion te gebruiken voor een wederzijdse gegevensuitwisseling, zolang je geen ingewikkelde handelingen uitvoert die de vertaler van de gegevens in verwarring brengen.

Investeer tot slot in het communiceren van de veranderingen aan het team: de motivatie, het waarom en een aantal stappen om dat te doen. Kies een 'early adopter'-team met engineers die ervaring hebben in de gehele levenscyclus van softwareontwikkeling en laat dat team een voorbeeld zijn voor de anderen. Zoek Git-kampioenen die mensen helpen als ze problemen ondervinden. Dit proces kan slagen dankzij kleine, begrijpelijke, iteratieve wijzigingen.

Step 6: Mirrors and clusters

Perforce heeft een eenvoudig maar effectief systeem voor het spiegelen van gegevens naar afgelegen locaties om het effect van latentie te verminderen. De tool heeft een complexer systeem om een set lokale mirrors te laten draaien voor alleen-lezen clustering. Latentie is voor Git gewoon niet zo'n probleem, maar als je een wereldwijd bedrijf runt is Bitbucket Data Center aan te bevelen voor zowel clustering als mirroring. Hierdoor zullen je kloontijden voor een wereldwijd team enorm versnellen.

Step 7: ALM tools

En nu goed nieuws: als je van Perforce naar Git overstapt, heb je veel keuzes voor je ALM-toolstack. Vrijwel elke ontwikkelaar en ALM-tool die er is, werkt met Git. En natuurlijk biedt Bitbucket je een geweldige integratie met Jira en Bamboo. Tijdens je transitie naar Git kun je de functies van Bamboo verkennen, zoals planbranches, die gebruikmaken van een workflow voor functiebranches.

Stap 8: Succes definiëren

Hoe meet je nu precies het succes tijdens een migratie van Perforce naar Git? In veel migratieprojecten richten we ons te veel op de getrouwheid van de gegevensoverdracht. Maar dat is om verschillende redenen geen bruikbare statistiek. Waarschijnlijk zul je in Git nooit een bit-voor-bit-geschiedenis krijgen die precies het equivalent is van wat er gebeurde in een gecentraliseerd SCM-systeem zoals Perforce.

Een meer praktische benadering is om CI/CD te gebruiken voor verificatie. Slagen al je tests nog steeds als je eenmaal je CI/CD-pipeline van Perforce naar Git hebt overgezet? En kun je je software nog steeds implementeren? Als al je belangrijke oudere builds nog steeds door je CI/CD-pipeline passen, mag je de overwinning uitroepen!

Dat was het dan ...

Je hebt nu gezien waarom er van Perforce naar Git wordt overgestapt, en hoe je daar daadwerkelijk komt. De volgende stap bestaat uit het kiezen van een Git-oplossing. Mocht je vanuit Perforce overstappen voor de ontwikkeling van games, lees dan waarom spelontwikkelaars zo dol zijn op Bitbucket.