Close

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

Come abbiamo discusso nell'articolo precedente, Git è ora la scelta SCM di fatto per quasi tutti i tipi di sviluppo digitale. Ma se hai anni di storia preziosa archiviati in Perforce, probabilmente stai valutando con cura le eventuali problematiche legate a un cambiamento. In questo articolo affronteremo di petto questi dubbi e ti spiegheremo come migrare i dati su Git. Abbiamo suddiviso il processo di migrazione da Perforce a Git in 8 passaggi:


Fase 1: Spostamento dei dati Perforce

Esistono due approcci generali per spostare i dati da Perforce a Git. Prima di approfondire quest'area, dobbiamo considerare una differenza fondamentale tra il modo in cui Perforce e Git gestiscono i progetti software.

Un server Perforce può contenere decine o centinaia di progetti software distinti, ognuno con il proprio modello di ramificazione. Uno sviluppatore definisce una «visualizzazione» che indica al server Perforce quali file inserire in una copia funzionante. Un repository Git, d'altra parte, normalmente contiene un singolo progetto software e i relativi branch e tag (sebbene esistano grandi repository Git monolitici). Di solito cloni il repository e, magari, dai un'occhiata ai sottomoduli o ai sottoalberi.

La questione dello spostamento dei dati, quindi, è divisa in due parti: come estrarre i dati da Perforce e come tradurli in un set equivalente di repository Git.

Spostamento dei dati Perforce, opzione 1: utilizzo di Git Fusion

Se vuoi conservare l'intera cronologia dei tuoi dati in Perforce, puoi utilizzare lo strumento Git Fusion di Perforce per estrarre una sezione di un server Perforce (un singolo progetto) in un repository Git. Essenzialmente:

Database
materiale correlato

Come spostare un repository Git completo

Logo di Bitbucket
Scopri la soluzione

Impara a utilizzare Git con Bitbucket Cloud

  • Installi Git Fusion
  • Imposta le visualizzazioni corrette dei tuoi dati, inclusa la struttura ramificata
  • Usa qualsiasi client Git per clonare da Git Fusion
  • Invia il tuo repository a 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.

Ora, potresti non avere sempre una copia fedele al 100% dei tuoi dati Perforce. Ci sono alcune operazioni di Perforce, come le fusioni parziali, che semplicemente non hanno equivalenti in Git. Ma tutto sommato, questo metodo acquisirà la maggior parte della tua cronologia senza troppi sforzi.

Tieni presente che preservare gli ultimi 10 anni di cronologia branch da un sistema SCM precedente non significa dover continuare a utilizzare lo stesso flusso di lavoro. In particolare, dovresti prendere in considerazione l'adozione di flussi di lavoro per i branch di funzionalità come Git Flow come primo passo pratico.

Pro e contro

  • Richiede la massima durata e configurazione
  • Conserva la maggior parte della cronologia (permettendoti di chiudere il server Perforce precedente)
  • Mantiene il modello di branch precedente nella cronologia

Spostamento dei dati di Perforce, opzione 2: ricominciare

L'altra opzione è ricominciare da capo. Dimentica tutta quella cronologia complessa: basta estrarre la testa (punta) di ogni branch in Perforce che corrisponde al tuo progetto e inserirla in un nuovo repository Git vuoto. Ciò implica il fatto di avere spazi di lavoro Perforce definiti con una «visualizzazione» corretta dei dati che desideri.

Questa è la tecnica più semplice e veloce. Non importa quanto fosse complicata la tua cronologia Perforce, il tuo nuovo repository Git sarà snello ed efficace. Hai la possibilità di avviare un nuovo flusso di lavoro basato su Git senza ostacoli.

Lo svantaggio principale è che probabilmente vorrai mantenere il vecchio server Perforce in modalità di sola lettura nel caso qualcuno abbia bisogno di scavare nel codice cronologico per qualsiasi motivo. Questo non ti costerà nulla in termini di licenza, ma implica dover mantenere in vita quel vecchio server per un po'.

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

Pro e contro

  • Veloce e semplice
  • Riprogettazione del modello di branching e del flusso di lavoro
  • Server Perforce legacy utilizzato per l'accesso in sola lettura

Passaggio 2: utenti e autorizzazioni

Dopo lo spostamento dei dati, la task successiva solitamente consiste nell'iniziare a mappare i tuoi utenti e le tue autorizzazioni in nuovi progetti Bitbucket. Se usi LDAP per un elenco utenti, risparmierai un po' di tempo qui. Altrimenti, puoi facilmente estrarre un set di account utente da Perforce usando il comando p4 users –o e poi inserirli in Bitbucket un progetto alla volta.

Tradurre le autorizzazioni Perforce nelle autorizzazioni Bitbucket equivalenti può essere difficile perché le autorizzazioni Perforce sono granulari e complesse, con la possibilità di escludere l'accesso a singoli file. Questo complicato schema di autorizzazione è uno dei motivi per cui un server Perforce può bloccarsi: ogni tentativo di accesso può far sì che il server esegua un calcolo costoso su una struttura dati complicata.

Nella maggior parte dei casi è più veloce chiedere ai responsabili del progetto di definire un set più semplice di autorizzazioni in Bitbucket utilizzando le normali autorizzazioni a livello di progetto, repository e branch. In effetti, vorrai comunque rivedere la configurazione delle tue autorizzazioni, poiché Git offre davvero tante nuove opzioni di flusso di lavoro. Ad esempio, in Perforce potresti aver limitato la creazione di branch, mentre in Bitbucket potresti dover limitare solo l'accesso push al branch principale.

Fase 3: file binari

Se hai archiviato grandi blob binari in Perforce, pensa attentamente a come vuoi gestirli in Git. Potresti provare Git LFS, oppure potresti semplicemente usare un normale sistema di gestione degli artefatti. In ogni caso ti consigliamo di non eseguire semplicemente il push di blob di grandi dimensioni in un repository Git.

Fase 4: dipendenze complesse

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.

Fase 5: come strutturare il tuo team durante la migrazione

Quindi, il tuo server Perforce ha 100 progetti da 10 team. Hai una strategia e un set di strumenti per la migrazione predisposti. Pianifica la finestra di manutenzione e vai!

Ehm... no.

Ricorda che cambiare strumento SCM riguarda tanto gli sviluppatori quanto i dati. Hai persone, procedure e orari da considerare: non cercare di fare tutto in una volta sola. È troppo rischioso.

Devi prendere in considerazione un piano di progetto durante la fase effettiva della migrazione. Potrebbe ad esempio essere un buon momento per provare un nuovo flusso di lavoro in Jira oppure ecco altre opzioni che puoi esaminare.

  • Esegui la migrazione squadra per squadra e progetto per progetto. Cerca di avviare un progetto e un team all'inizio di uno sprint o di un incremento del programma, quando hai del tempo per adattarti.
  • Migra in modo incrementale. Importa tutti i tuoi dati in un fine settimana, ma poi lascia che i team completino lentamente il passaggio a Git nel tempo. Ritira periodicamente i delta rieseguendo gli strumenti di importazione. Sebbene sia più complessa, questa strategia è ideale se hai dipendenze tra i team e gli early adopter hanno bisogno almeno di un'istantanea recente in Git da inserire nella loro pipeline CI/CD.
  • Usa entrambi i sistemi contemporaneamente per un periodo di tempo. Anche se non è una scelta semplice, è tecnicamente fattibile usare Git Fusion per fare uno scambio di dati bidirezionale purché non si eseguano operazioni complesse che confonderanno il traduttore di dati.

Infine, prendi del tempo per comunicare i cambiamenti al team: la motivazione, il perché e una serie di passaggi su come farlo. Scegli un team di «early adopter» con ingegneri esperti nell'intero ciclo di vita dello sviluppo del software e chiedi a quel team di fungere da modello per gli altri. Trova campioni Git che aiutino le persone quando hanno difficoltà. Apportare modifiche piccole, comprensibili e iterative aiuterà questo processo ad avere successo.

Step 6: Mirrors and clusters

Perforce dispone di un sistema semplice ma efficace per il mirroring dei dati su siti remoti per ridurre l'effetto della latenza. Ha un sistema più complesso per l'esecuzione di un set di mirror locali per il clustering di sola lettura. Sebbene la latenza semplicemente non sia così preoccupante per Git, se stai eseguendo un'operazione in tutto il mondo dovresti dare un'occhiata a Bitbucket Data Center sia per il clustering che per il mirroring, che velocizzerà notevolmente i tempi di clonazione per un team globale.

Step 7: ALM tools

E ora una buona notizia: hai molte scelte per il tuo stack di strumenti ALM quando passi da Perforce a Git. Praticamente tutti gli strumenti per sviluppatori e ALM disponibili funzionano con Git e ovviamente Bitbucket ti offre un'ottima integrazione con Jira e Bamboo. Durante la transizione a Git, puoi esplorare le funzionalità di Bamboo come i Plan Branches, che sfruttano il flusso di lavoro di un branch di funzionalità.

Fase 8: definire il successo

Quindi, come si misura esattamente il successo durante una migrazione da Perforce a Git? In molti progetti di migrazione tendiamo a concentrarci troppo sulla fedeltà del trasferimento dei dati. Ma questa non è una metrica utile per molte ragioni. È probabile che non si possa mai ottenere una cronologia bit per bit in Git che sia esattamente l'equivalente degli eventi in un sistema SCM centralizzato come Perforce.

Un approccio più pratico consiste nell'utilizzare CI/CD per la verifica. Una volta che passi la tua pipeline CI/CD da Perforce a Git, tutti i tuoi test sono ancora validi? E puoi ancora distribuire il tuo software? Se tutte le tue importanti build più vecchie possono ancora passare attraverso la tua pipeline CI/CD, allora il tutto ha avuto successo.

E questo è tutto

Quindi ora hai capito perché assistiamo a uno spostamento da Perforce a Git e come farlo in concreto. Il passaggio successivo è scegliere una soluzione Git. Se stai passando da Perforce per lo sviluppo di giochi, scopri perché gli sviluppatori di giochi amano Bitbucket.


Condividi l'articolo
Argomento successivo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Le persone collaborano utilizzando una parete piena di strumenti

Blog di Bitbucket

Illustrazione su Devops

Percorso di apprendimento DevOps

Funzione Demo Den per demo con esperti Atlassian

Come Bitbucket Cloud funziona con Atlassian Open DevOps

Iscriviti alla nostra newsletter DevOps

Thank you for signing up