Close

A step-by-step guide to migrating from Perforce to 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:


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:

Databases
gerelateerd materiaal

Een volledige Git-repository verplaatsen

Logo Bitbucket
Oplossing bekijken

Git leren met Bitbucket Cloud

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

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.

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

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

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.


Deel dit artikel
Volgend onderwerp

Aanbevolen artikelen

Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.

Mensen die samenwerken met een muur vol tools

Bitbucket-blog

Toelichting DevOps

DevOps-leertraject

Demo Den Feature-demo's met Atlassian-experts

Hoe Bitbucket Cloud werkt met Atlassian Open DevOps

Meld je aan voor onze DevOps-nieuwsbrief

Thank you for signing up