Een stapsgewijze handleiding voor de migratie van Perforce naar Git

Zoals we in het vorige artikel hebben besproken, is Git nu dé feitelijke keuze voor SCM voor zowat elke vorm van digitale ontwikkeling. Maar als je jaren aan waardevolle geschiedenis in Perforce hebt opgeslagen, dan weeg je waarschijnlijk de kosten van een overstap af. In dit artikel gaan we rechtstreeks in op deze vraag en vertellen we je hoe je gegevens naar Git migreert. We hebben het migratieproces van Perforce naar Git opgedeeld in 8 stappen:

• Perforce-gegevens verplaatsen
• Gebruikers en machtigingen toewijzen aan een nieuwe Git-repo
• Grote binaire bestanden
• Complexe afhankelijkheden
• Je team structureren tijdens de migratie
• Gegevens spiegelen
• ALM-tools
• Het succes van een migratie van Perforce naar Git bepalen

Stap 1: Perforce-gegevens verplaatsen

Er zijn twee algemene manieren om de gegevens van Perforce naar Git te verplaatsen. Voordat we daarop ingaan, moeten we het hebben over een fundamenteel verschil tussen de manier waarop Perforce en Git omgaan met softwareprojecten.

Een Perforce-server kan tientallen of honderden verschillende softwareprojecten bevatten, elk met een eigen vertakkingsmodel. Een ontwikkelaar definieert een 'weergave' die aan de Perforce-server vertelt welke bestanden in een werkkopie moeten worden geplaatst. Een Git-repository daarentegen bevat normaal gesproken één softwareproject en de bijbehorende branches en tags (hoewel er ook grote monolithische Git-repo's bestaan). Meestal kloon je de repo en bekijk je misschien submodules of substructuren.

De vraag over het verplaatsen van de gegevens bestaat dus uit twee delen: hoe haal je gegevens uit Perforce? En hoe vertaal je die naar een gelijkwaardige set Git-repository's?

Perforce-gegevens verplaatsen, optie 1: Git Fusion gebruiken

Als je de volledige geschiedenis van je gegevens in Perforce wilt bewaren, kun je de eigen Git Fusion-tool van Perforce gebruiken om een deel van een Perforce-server (een enkel project) te extraheren naar een Git-repo. Feitelijk doe je het volgende:

• Installeer Git Fusion
• Stel de juiste weergaven van je gegevens in, inclusief de branchstructuur
• Gebruik een willekeurige Git-client om vanuit Git Fusion te klonen
• Push je repo naar Bitbucket

 Voorbeeld uit de praktijk *Om dit voorbeeld te kunnen gebruiken, heb je een Perforce-server nodig waarop Git Fusion al operationeel is.* Stel dat je een Perforce-project hebt in het pad van de repository //depot/acme/… (in de Perforce depot view syntax). Het heeft drie branches: - //depot/acme/main/… - //depot/acme/r1.0/… - //depot/acme/r1.1/… Houd er rekening mee dat je Perforce-branches als extra mappen in de boomstructuur ziet. Je eerste stap is om Git Fusion zo te configureren dat het de vertakkingsrelatie in Perforce begrijpt. Om dit te doen, maak je een repoconfiguratiebestand aan: [@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/… … Verzend dit bestand naar Perforce onder het pad //.git-fusion/repos/acme/p4gf_config Maak nu in Bitbucket een leeg project met de naam acme met de normale beheertools van Bitbucket. Je kunt de toegangscontrole en de teamleden configureren volgens je gebruikelijke normen. Maak vervolgens een kloon uit Git Fusion: git clone https:///acme cd acme git remote add bitbucket  git push –u --all bitbucket git push --tags Bitbucket Dat is alles! Je zou nu de geïmporteerde geschiedenis moeten zien in Bitbucket.

Dit geeft je niet altijd een 100% getrouwe kopie van je Perforce-gegevens. Sommige Perforce-bewerkingen, zoals gedeeltelijke samenvoegingen, hebben gewoon geen equivalent in Git. Maar al met al voorziet deze methode zónder al te veel moeite in het grootste deel van je geschiedenis.

Bedenk je dat wanneer je je branches van de laatste 10 jaar op basis van een oude SCM bewaarde, dat niet betekent dat je dezelfde workflow moet blijven gebruiken. Je zou met name moeten overwegen om als praktische eerste stap workflows voor verschillende branches toe te passen, zoals Git Flow.

Voor- en nadelen

• Vereist de meeste configuratie en uitvoeringstijd
• Bewaart de meeste geschiedenis (zodat je de oude Perforce-server kunt afsluiten)
• Behoudt het oude branchmodel in de geschiedenis

Perforce-gegevens verplaatsen, optie 2: opnieuw beginnen

De andere optie is om opnieuw te beginnen. Vergeet al die slechte geschiedenis. Haal gewoon de head (uiterste) van elke branch in Perforce op die overeenkomt met je project en stop 'm in een nieuwe, lege Git-repo. (Dit houdt in dat je Perforce-werkruimten hebt gedefinieerd met een juiste 'weergave' van de gewenste gegevens.)

Dit is de eenvoudigste en snelste techniek. Hoe ingewikkeld je Perforce-geschiedenis ook was, je nieuwe Git-repo is lean en mean. Je krijgt de kans om zonder al te veel bagage een nieuwe Git-workflow te starten.

Het grootste nadeel is dat je waarschijnlijk de oude Perforce-server in de modus Alleen-lezen wilt houden voor het geval iemand om wat voor reden dan ook in historische code moet duiken. Dit kost je geen licentiekosten, maar het betekent wel dat je die oude server een tijdje draaiend moet houden.

 **Praktijkvoorbeeld** Ga naar je Perforce-werkruimte (de map waar de main-branch van je projectgegevens wordt uitgecheckt) en voer het volgende uit: p4 sync Hiermee wordt de laatste versie van je bestanden opgehaald. Maak nu in Bitbucket een leeg project met de naam acme met de normale beheertools van Bitbucket. Je kunt de toegangscontrole en de teamleden configureren volgens je gebruikelijke normen. Maak vervolgens een nieuwe Git-repo in je werkruimte en push deze naar Bitbucket: git init . git remote add origin  git push -u --all origin git push --tags origin Als het goed is, zie je nu de nieuwste snapshot van je code als eerste commit in je nieuwe Bitbucket-project.

Voor- en nadelen

• Snel en eenvoudig
• Branching-model en -workflow opnieuw ontwerpen
• Oude Perforce-server gebruikt voor alleen-lezentoegang

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

Een werkkopie van Perforce kan in feite gegevens uit verschillende modules in kaart brengen die alleen gelezen kunnen worden. In Git wordt dit ofwel gedaan met submodules, substructuren, ofwel door gebruik te maken van CI/CD- of artefactbeheersystemen. Hier is geen eenvoudig antwoord op te geven, maar sommige tools voor het importeren van gegevens kunnen een submodule-relatie tussen Git-repo's modelleren. Een uitgebreidere uitleg over het gebruik van submodules of substructuren vind je hier https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-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.

Stap 6: Mirrors en 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.

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