Perforce naar Git: waarom de overstap?

Workflow

Afgezien van alle toeters en bellen gaat een SCM-tool in wezen over samenwerking: een team van ontwikkelaars laten werken aan een gedeelde set softwarebestanden. Git biedt eenvoudige en computationeel voordelige branches, wat de deur opent naar een verscheidenheid aan coole workflows. Taakbranching, Git Flow, vertakte repository's: er is een snelle en eenvoudige workflow voor elk type team, van open source tot professionele ontwikkeling, ondersteund door krachtige tools voor codebeoordeling en samenwerking.

Git maakt het ook eenvoudig om over bedrijfsgrenzen heen samen te werken, wat vaak nodig is bij cross-functionele ontwikkeling. Zelfs als fysieke netwerktoegang tot een gedeelde Git-repository niet mogelijk is, maken de Git-patch en -bundeltools het delen van gegevens eenvoudig.

Perforce houdt daarentegen een branchingrecord bij per bestand, vergeleken per commit in Git. Wat houdt dat in? Nou, om te beginnen creëert het ontzettend veel metadata in de Perforce-database elke keer dat je een branch aanmaakt. Dat draagt bij aan prestatieproblemen bij grotere implementaties, in de mate dat veel Perforce-beheerders het aanmaken van branches beperken.

Houd daar even rekening mee: elke keer dat je een taak-branch wilt aanmaken om een nieuwe functie uit te proberen, moet je om toestemming vragen. Als je geen taak-branches kunt maken, kun je de instabiele code in de main-branch inchecken, of gewoon wachten tot je 'voltooid' bent voordat je iets vastlegt. Je offert het voordeel op van CI/CD in je taak-branches en de mogelijkheid om werk in uitvoering gedetailleerd te kunnen volgen. Het eindresultaat is een lagere productiviteit, aangezien ontwikkelaars ofwel met minder productieve workflows leven of gewoon Git gaan gebruiken om erachter te komen hoe ze hun werk handmatig kunnen samenvoegen met Perforce.

Behalve dat ze duur zijn, zijn Perforce-branches niet bevorderlijk voor het soort workflow waar de meeste ontwikkelaars de voorkeur aan geven. Perforce-branches worden gedeeld, dus er bestaat niet zoiets als een privébranch met periodieke rebasing. En de samenvoegingsalgoritmen van Perforce zijn te ingewikkeld, want er zijn hele artikelen geschreven over het samenvoegen van bestanden waarvan de naam is gewijzigd of waarvan de attributen zijn gewijzigd.

En het delen van code tussen Perforce-servers? Je bent weer bezig met het delen van tar-bestanden zonder gemeenschappelijke geschiedenis. Volgens het gegevensmodel van Perforce is softwaregeschiedenis uniek voor een enkele server, vergeleken met de eenvoudige mogelijkheid van Git om overal geschiedenis te klonen en te delen.

Mindshare en community

Afgezien van commerciële concurrenten, waarom heeft Git Mercurial en andere waardige concurrenten verslagen? Momentum heeft natuurlijk enige waarde, en Git heeft dat. Git is gemaakt door Linus Torvalds om de uitdagingen op het gebied van gedistribueerde ontwikkeling van het Linuxkernel-project op te lossen, en is nu de standaard SCM-tool voor Linux, Android, OpenStack en de meeste andere belangrijke opensourceprojecten. Dat is wat alle coole kinderen gebruiken, dus als je een recruiter bent, kun je er waarschijnlijk van uitgaan dat een nieuwe engineer met Git kan (en wil) werken zonder dat daarvoor uitgebreide training nodig is.

En natuurlijk heb je de volledige kracht van een levendige opensourcecommunity die achter Git staat. Git ontwikkelt zich snel om problemen uit de echte wereld op te lossen, met belangrijke nieuwe functies zoals Git LFS die op de markt verschijnen. Je kunt je eigen code aan het Git-project bijdragen als er een bug is waarvan je wilt dat die opgelost wordt, en je zult nooit vastzitten aan een commercieel product met een roadmap en een tempo dat door één bedrijf wordt bepaald. Kijk maar naar het aanbod aan Git-clientprogramma's dat beschikbaar is: verschillende krachtige GUI's voor desktops, integratie met Windows Explorer, plug-ins voor elke IDE en elke developertool.

GUI's en tools voor ontwikkelaars

In de eerste dagen van Git lieten de GUI en de support voor tools wat te wensen over. Dit was een struikelblok voor gebruikers die de voorkeur geven aan een visuele interface voor interactie met hun Git-repository's. Niet-technische medewerkers, zoals gamekunstenaars, hadden in het bijzonder weinig rechten. De Windows Explorer-plug-in van Perforce was een hit bij dit publiek.

Maar gelukkig zijn die dagen voorbij. GUI's zoals Sourcetree bieden een point-and-click-ervaring en er zijn talloze shell-integraties voor Git. Bitbucket biedt coderevisie, merge- en pull-aanvragen, vertakkingen, online browsen op code en een overvloed aan andere samenwerkingstools. Inderdaad, iedereen, van datawetenschappers tot creatieve bureaus, organiseert community's die gebruikmaken van de open samenwerking die Git en Bitbucket mogelijk maken.

Game-ontwikkelaars zijn bijzonder

Dat gezegd hebbende, wat heeft sommige community's, zoals game-ontwikkelaars en onderzoekers, die met enorme datasets te werken, ervan weerhouden zich bij deze beweging aan te sluiten? Het komt allemaal neer op het soort gegevens en de complexiteit van de projectorganisatie.

Binaire bestanden

Game-ontwikkelaars, met name artiesten, moeten met grote binaire objecten werken, zoals texturen en audiomateriaal. Datawetenschappers hebben mogelijk enorme datasets, bestaande uit miljarden eventsamples.

Dat levert twee problemen op voor Git.

• Deze bestanden kunnen niet worden samengevoegd. Een gecentraliseerd vergrendelingsmechanisme is handig, en Perforce biedt er een. (Houd er echter rekening mee dat zelfs een gecentraliseerde server slechts een vergrendelingsmechanisme op één branch biedt, dus als je op deze functie vertrouwde, had je een zeer beperkte workflow.)
• Deze bestanden zorgen ervoor dat Git trager wordt naarmate de repository groter wordt.

Het probleem met de grootte van de repository wordt grotendeels opgelost door Git LFS, een extensie waarmee Git grote bestanden kan verwerken en de eigenlijke bestandsopslag naar een andere plek kan delegeren.

Het probleem van de vergrendeling van bestanden vereist onderzoek op twee fronten. Vanuit het oogpunt van softwareconfiguratiebeheer heeft Git LFS een superieure vorm van bestandsvergrendeling op de roadmap. Git LFS helpt bij het coördineren van het vergrendelen van binaire bestanden in meerdere branches met een algoritme dat ervoor zorgt dat je aan de laatste versie werkt, ongeacht in welke branch je actief bent. Dat maakt vertakte workflows toegankelijk voor gebruikers die met grote binaire bestanden werken, vergeleken met het vergrendelingsmodel van Perforce met één branch.

Het is ook handig om het vergrendelen van bestanden als een coördinatieprobleem te beschouwen. Als je gaat werken aan een gedeeld bezit dat niet kan worden samengevoegd, hoe zend je die kennis dan naar alle geïnteresseerde partijen? Nogmaals, hier schittert de komst van moderne workflows met pull-aanvragen en realtime teamsamenwerking. Je kunt snel je bedoelingen kenbaar maken via HipChat en controleren of er nog werk in uitvoering is met betrekking tot een bepaald bestand.

Het is ook interessant om te bedenken hoe het probleem van de verwerking van grote bestanden zal evolueren in het tijdperk van Big Data. Om een Big Data-analysetaak te testen, heb je mogelijk een dataset nodig die meerdere terabytes groot is. Vergeet elk SCM-systeem, dit project is getest en draait op een bestandssysteem dat compatibel is met Big Data. Wat hier nodig is, is een CI/CD-systeem dat een complexere pipeline kan orkestreren met artefacten die leven op HDFS of S3. Dat leidt naar ons volgende onderwerp.

Grote projecten

De ontwikkeling van games is een klassiek voorbeeld van een softwareproject met meerdere modules of componenten: de game-engine, de gebruikersinterface, statische afbeeldingen, videoweergaven, enzovoort. Perforce kan als monolithische centrale repository al deze modules op één server hosten, zodat gebruikers kunnen kiezen welke onderdelen ze in hun eigen werkruimte willen gebruiken.

Dit voordeel is nu echter grotendeels betwistbaar. Moderne Git-systemen zoals Bitbucket zorgen voor een eenvoudiger beheer van Git-tools voor meerdere modules, zoals submodules en substructuren. En nog belangrijker, grote projecten zoals Android hebben laten zien hoe je een complex project kunt beheren met compositietools op een hoger niveau. Veel van deze lessen zijn meegenomen in moderne CI/CD-tools zoals Bamboo en Bitbucket Pipelines, waarmee complexe workflows voor continue integratie kunnen worden georkestreerd, de afhankelijkheden tussen projecten kunnen worden gemodelleerd en artefacten tussen projecten kunnen worden beheerd.

Deze trend volgt grotendeels de Git (en *nix)-filosofie om een tool te ontwikkelen die één taak heel goed doet. Continue integratie en continue levering (CI/CD) is een werkwijze an sich, met tools die erop gericht zijn om de workflow voor bouwen en releasen te begrijpen. Het komt ook overeen met de best practices voor moderne softwareontwikkeling, die gericht zijn op het gebruik van kleine, op zichzelf staande microservices in plaats van monolithische projecten.

Volgende stappen

Het 'Perforce naar Git'-kamp heeft duidelijk wat momentum gekregen, en Git en moderne CI/CD-tools zijn er nu klaar voor om de grootste en meest complexe ontwikkelingsinspanningen aan te kunnen. Perforce heeft zelfs een tool gemaakt, genaamd Git Fusion, waarmee je een deel van een centrale Perforce-repository kunt extraheren als Git-repository.

Hoewel Git Fusion een nobele inspanning was, is het helaas niet zo eenvoudig om Git in een gecentraliseerd SCM-systeem te plaatsen. Als je probeert je gebruiksmodellen te combineren, kun je heel eenvoudig de gegevensweergave van één systeem beschadigen. Als je je gebruiksmodellen niet met elkaar combineert, is het moeilijk in te zien wat het waard is om een commercieel gecentraliseerde backend achter Git te zetten. Zoals we hebben gezien, gaat de trend in feite de andere kant op: hoe zet je de laatste paar overgebleven stukjes gecentraliseerd SCM die nuttig waren in Git in?

Als je Perforce gebruikt voor de ontwikkeling van software of games, vraag je je waarschijnlijk (zenuwachtig) af hoe je naar Git kunt migreren. Hoe doe je dat eigenlijk? En is het de overstapkosten waard? Dat is precies wat we in het volgende artikel zullen behandelen.