Perforce to Git: Why make the move

Flusso di lavoro

Andando al punto della questione, fondamentalmente uno strumento SCM si basa sulla collaborazione: deve consentire ai team di sviluppatori di lavorare su un set condiviso di file del software. Git offre funzioni di creazione di branch semplici ed economiche dal punto di vista computazionale che rendono disponibili diversi flussi di lavoro interessanti. Creazione di branch dei task, Git Flow, repository sottoposti a fork: c'è un flusso di lavoro facile e veloce per qualsiasi tipo di team, da quello di sviluppo open source a quello composto da sviluppatori professionisti, con il supporto di potenti strumenti di revisione del codice e di collaborazione.

Git semplifica inoltre la collaborazione al di là dei confini aziendali, un requisito comune dello sviluppo interfunzionale. Anche se l'accesso di rete fisico a un repository condiviso Git non è disponibile, gli strumenti di pacchetto e applicazione di patch di Git semplificano la condivisione dei dati.

Perforce, d'altra parte, detiene il record di creazione di branch basata sui singoli file, rispetto a quella basata sui singoli commit di Git. Cosa significa esattamente? Beh, per cominciare, ogni volta che si crea un branch vengono creati moltissimi metadati nel database di Perforce. Ciò aggrava i problemi relativi alle prestazioni nelle distribuzioni più ampie e in alcuni casi molti amministratori Perforce si vedono addirittura costretti a limitare la creazione di branch.

Prova a immaginare: ogni volta che vuoi creare un branch dei task per provare una nuova funzione, devi andare a chiedere l'autorizzazione. Se non riesci a creare branch dei task, potresti inserire codice instabile nel branch principale o semplicemente aspettare di aver completato tutto prima di eseguire il commit. Rinunci al vantaggio della CI/CD nei branch dei task e alla possibilità di monitorare in modo granulare il lavoro in corso. Il risultato finale è una riduzione della produttività, dovuta al fatto che gli sviluppatori impiegano flussi di lavoro meno produttivi oppure semplicemente iniziano a usare Git come strumento secondario e scoprono come eseguire il merge manuale del proprio lavoro su Perforce.

Oltre ad essere costosi, i branch Perforce non sono adatti al tipo di flusso di lavoro preferito dalla maggior parte degli sviluppatori. I branch Perforce sono condivisi, quindi non esistono branch dei task privati con riassegnazioni periodiche. E gli algoritmi di merge di Perforce sono eccessivamente complicati, con interi articoli che spiegano come eseguire il merge dei file che sono stati rinominati o i cui attributi sono stati modificati.

E la condivisione del codice tra i server Perforce? Ci ritroviamo di nuovo a condividere file tar senza una cronologia comune. Il modello di dati di Perforce considera la cronologia software come univoca per un singolo server, rispetto alla possibilità offerta da Git di clonare e condividere con facilità la cronologia in qualsiasi posizione.

Mindshare e community

Al di là dei concorrenti commerciali, perché Git ha battuto Mercurial e altri meritevoli avversari? Ovviamente, lo slancio ha il suo peso, e Git non ne è privo. Git è stato creato da Linus Torvalds per risolvere le sfide dello sviluppo distribuito del progetto del kernel Linux e ora è lo strumento SCM standard per Linux, Android, OpenStack e per la maggior parte degli altri importanti progetti open source. È lo strumento usato dai migliori, quindi se sei un responsabile delle assunzioni, puoi dare per scontato che i nuovi ingegneri siano in grado di (e vorranno) lavorare con Git senza aver bisogno di ricevere una formazione approfondita.

E, naturalmente, puoi contare sul pieno appoggio della vivace community open source a sostegno di Git. Git si sta evolvendo rapidamente per risolvere i problemi del mondo reale, con nuove importanti funzioni, come Git LFS, in arrivo a breve. Puoi contribuire con il tuo codice al progetto Git se c'è un bug che vuoi vedere corretto e non ti ritroverai mai bloccato con un prodotto commerciale con una roadmap e un ritmo stabiliti da un'unica azienda. Basta dare un'occhiata alla gamma di programmi client Git disponibili: diverse GUI desktop potenti, integrazione con Windows Explorer e plugin per ogni IDE e strumento per sviluppatori.

GUI e strumenti per sviluppatori

Agli inizi di Git, la GUI e il supporto degli strumenti erano alquanto carenti. Questo ha rappresentato un ostacolo per gli utenti che preferiscono un'interfaccia visiva per interagire con i propri repository Git. I collaboratori non tecnici, come i game artist in particolare, non erano quasi per niente rappresentati. Il plugin Windows Explorer di Perforce ha riscosso un ampio successo presso questo tipo di pubblico.

Ma per fortuna quei giorni sono passati. Le GUI come Sourcetree offrono un'esperienza intuitiva e vi sono moltissime integrazioni della shell per Git. Bitbucket rende disponibili revisione del codice, merge e pull request, fork, navigazione nel codice online e una miriade di altri strumenti di collaborazione. A dire il vero, tutti i professionisti, dai data scientist alle agenzie creative, stanno creando community che sfruttano la collaborazione aperta resa possibile da Git e Bitbucket.

Gli sviluppatori di giochi sono un caso speciale

Detto questo, cosa ha impedito ad alcune community come quella degli sviluppatori di giochi e dei ricercatori che lavorano con enormi set di dati di seguire il trend? Tutto si riduce al tipo di dati e alla complessità dell'organizzazione del progetto.

File binari

Gli sviluppatori di giochi, in particolare i game artist, devono lavorare con oggetti binari di grandi dimensioni come le trame e le risorse audio. I data scientist potrebbero dover gestire enormi set di dati che includono miliardi di campioni di eventi.

Ciò pone due problemi per Git.

• Questi file non possono essere sottoposti a merge. Torna utile un meccanismo di blocco centralizzato, e Perforce ne offre uno (tieni tuttavia presente che persino un server centralizzato offre un meccanismo di blocco solo su un singolo branch, quindi fare affidamento su questa funzione implica la presenza di un flusso di lavoro molto limitato).
• Questi file rallentano le prestazioni di Git man mano che le dimensioni del repository aumentano.

Il problema relativo alle dimensioni del repository è in gran parte risolto da Git LFS, un'estensione che consente a Git di gestire file di grandi dimensioni delegando l'effettivo spazio di archiviazione dei file in un'altra posizione.

Il problema del blocco dei file può essere esaminato su due fronti. Dal punto di vista della gestione della configurazione software, Git LFS offre un livello superiore di blocco dei file nella roadmap. Git LFS è in grado di coordinare il blocco dei file binari su più branch tramite un algoritmo che ti garantisce di lavorare sulla versione più recente, indipendentemente dal branch in cui ti trovi. Ciò rende disponibili agli utenti che lavorano con file binari di grandi dimensioni dei flussi di lavoro di creazione di branch, rispetto al modello di blocco a branch singoli di Perforce.

È anche utile pensare al blocco dei file come a un problema di coordinamento. Se hai intenzione di iniziare a lavorare su una risorsa condivisa che non può essere sottoposta a merge, come fai a trasmettere le informazioni a tutte le parti interessate? Ancora una volta, è qui che l'avvento dei flussi di lavoro moderni che utilizzano le pull request e la collaborazione tra team in tempo reale dà i suoi frutti migliori. Puoi comunicare rapidamente le tue intenzioni utilizzando HipChat e verificare se c'è del lavoro in corso su un determinato file.

È inoltre interessante esaminare come si evolverà il problema della gestione dei file di grandi dimensioni nell'era dei Big Data. Per testare un lavoro di analisi dei Big Data, potrebbe essere necessario un set di dati di diversi terabyte. Dimentica i sistemi SCM: questo progetto viene testato ed eseguito su un file system compatibile con i Big Data. Ciò che serve in questo caso è un sistema CI/CD in grado di orchestrare una pipeline più complessa con artefatti che risiedono su HDFS o S3. E questo ci porta al prossimo argomento.

Progetti di grandi dimensioni

Lo sviluppo di giochi è un classico esempio di progetto software con più moduli o componenti: il motore del gioco, l'interfaccia utente, la grafica statica, i rendering video e così via. Perforce come repository centralizzato monolitico può ospitare tutti questi moduli in un unico server e consente agli utenti di decidere quali parti scegliere nel proprio spazio di lavoro.

Tuttavia, questo vantaggio è in gran parte opinabile al giorno d'oggi. I moderni sistemi Git, come Bitbucket, offrono una gestione più semplice degli strumenti multimodulo Git come i sottomoduli e i sottoalberi. E, cosa ancora più importante, i progetti di grandi dimensioni come Android hanno mostrato come gestire un progetto complesso utilizzando strumenti di composizione di livello superiore. Molti di questi insegnamenti sono stati integrati nei moderni strumenti CI/CD, come Bamboo e Bitbucket Pipelines, che sono in grado di orchestrare flussi di lavoro complessi di continuous integration, modellare le dipendenze tra i progetti e gestire gli artefatti tra i progetti.

Questa tendenza segue in gran parte la filosofia Git (e *nix) di compilare uno strumento che svolga alla perfezione un unico task. La continuous integration e la continuous delivery (CI/CD) sono una pratica a parte, con strumenti dedicati alla comprensione del flusso di lavoro di compilazione e rilascio. Ciò è inoltre in linea con le moderne best practice di sviluppo software, che mirano a utilizzare piccoli microservizi autonomi anziché progetti monolitici.

Prossimi passi

Sul fronte del passaggio da Perforce a Git si sta chiaramente verificando un certo slancio e Git e i moderni strumenti CI/CD sono ora pronti a gestire i lavori di sviluppo più ampi e complessi. Infatti, Perforce ha persino creato uno strumento chiamato Git Fusion che consente di estrarre parte di un repository Perforce centrale come repository Git.

Purtroppo, anche se Git Fusion è stato un nobile tentativo, provare a sovrapporre Git su un sistema SCM centralizzato non è molto facile; se si prova a mischiare i modelli di utilizzo, si può facilmente danneggiare la visualizzazione dei dati di un sistema. Se non si mischiano tali modelli, è difficile immaginare l'utilità di posizionare un backend commerciale centralizzato alla base di Git. La tendenza che abbiamo esaminato va in realtà nella direzione opposta: come si integrano in Git le poche ultime porzioni utili rimanenti della soluzione SCM centralizzata?

Se usi Perforce per lo sviluppo di software o giochi, probabilmente ti starai chiedendo (con ansia) come effettuare la migrazione a Git. Da dove si comincia? E vale la pena sostenerne il costo? Questo è esattamente l'argomento del prossimo articolo.