Da SVN a Git: preparazione alla migrazione

Script di migrazione di Atlassian

Se ti interessa effettuare una transizione subitanea a Git, gli script di migrazione di Atlassian sono una buona scelta. Questi script ti forniscono tutti gli strumenti necessari per trasformare in modo affidabile i repository SVN esistenti in repository Git. La cronologia nativa Git risultante garantisce che non sarà necessario affrontare alcun problema di interoperabilità da SVN a Git dopo il processo di conversione.

Abbiamo creato una guida tecnica completa per l'utilizzo di questi script per la conversione dell'intera base di codice in una raccolta di repository Git. In questa procedura dettagliata sono spiegati tutti i passaggi, dall'estrazione delle informazioni sull'autore in SVN alla riorganizzazione delle strutture di repository SVN non standard.

Plug-in SVN Mirror for Stash (ora Bitbucket)

SVN Mirror for StashSVN Mirror for Stash è un plug-in di Bitbucket che consente di mantenere agevolmente una base di codice ibrida che funziona sia con SVN che con Git. A differenza degli script di migrazione di Atlassian, SVN Mirror for Stash consente di utilizzare Git e SVN contemporaneamente sullo stesso progetto per tutto il tempo che desideri.

Questo compromesso è un'ottima opzione per le aziende più grandi perché consente l'adozione incrementale di Git permettendo ai diversi team di migrare i flussi di lavoro a loro piacimento.

Cos'è Git-SVN?

Lo strumento git-svn è un'interfaccia tra un repository Git locale e un repository SVN remoto. git-svn consente agli sviluppatori di scrivere codice e creare commit in locale con Git e quindi eseguirne il push a un repository SVN centrale con un comportamento in stile commit svn. Questa dovrebbe essere una procedura temporanea, ma è utile quando si deve decidere se effettuare il passaggio da SVN a Git.

git-svn è una buona opzione se non sei sicuro di passare a Git e vuoi dare ad alcuni degli sviluppatori la possibilità di esplorare i comandi Git senza impegnarsi in una migrazione completa. È la soluzione perfetta anche per la fase di formazione: invece di una transizione repentina, il team può procedere con calma usando i comandi Git locali prima di pensare ai flussi di lavoro di collaborazione.

Tieni presente che git-svn dovrebbe essere solo una fase temporanea del processo di migrazione. Poiché dipende ancora da SVN per il "backend", questo strumento non è in grado di sfruttare le funzioni Git più potenti come la creazione di branch o i flussi di lavoro di collaborazione avanzati.

Strategie di implementazione

La migrazione della base di codice è solo un aspetto dell'adozione di Git. Occorre anche considerare in che modo presentare Git alle persone dietro questa base di codice. I consulenti esterni, gli esperti Git interni e i team pilota sono le tre strategie principali per affrontare il passaggio del team di sviluppo a Git.

Consulenti Git esterni

I consulenti Git possono sostanzialmente gestire il processo di migrazione per tuo conto dietro pagamento di una tariffa nominale. In questo modo, avrai il vantaggio di disporre di un flusso di lavoro Git in grado di adattarsi perfettamente al team senza dover investire del tempo per crearlo in autonomia. Con questa soluzione, avrai inoltre a disposizione risorse di formazione avanzate per supportare l'apprendimento di Git da parte del team. Gli Atlassian Partner sono professionisti della migrazione da SVN a Git e rappresentano un'ottima risorsa per trovare un consulente Git.

D'altra parte, progettare e implementare un flusso di lavoro Git in autonomia è un ottimo modo per il team di comprendere il funzionamento interno del nuovo processo di sviluppo. In questo modo si evita il rischio che il team si ritrovi a brancolare nel buio quando il consulente se ne va.

Esperti interni di Git

Un esperto di Git è uno sviluppatore interno all'azienda che è entusiasta di iniziare a usare Git. Servirsi degli esperti di Git è una buona opzione per le aziende con una solida cultura incentrata sugli sviluppatori e con programmatori motivati che si sentono a proprio agio a provare per primi lo strumento. L'idea è consentire a uno degli ingegneri di diventare un esperto di Git in modo che possa progettare un flusso di lavoro Git su misura per la tua azienda e fungere da consulente interno quando è il momento di far passare il resto del team a Git.

Rispetto a un consulente esterno, questa soluzione presenta il vantaggio di mantenere le competenze su Git all'interno dell'azienda. Richiede tuttavia un investimento di tempo maggiore per formare l'esperto di Git, con il rischio di scegliere il flusso di lavoro Git sbagliato o di implementarlo in modo errato.

Team pilota

La terza opzione per affrontare il passaggio a Git è testare lo strumento con un team pilota. Questa soluzione è adatta se hai un team di piccole dimensioni che lavora su un progetto relativamente isolato. Oppure, ancora meglio, potresti affiancare i consulenti esterni e gli esperti interni di Git al team pilota per ottenere una combinazione vincente.

Il lato positivo di questo scenario è che rende necessaria l'approvazione di tutto il team, limitando anche il rischio di scegliere un flusso di lavoro sbagliato dal momento che tutti i membri del team possono dare il proprio contributo durante la progettazione del nuovo processo di sviluppo. In altre parole, in questo modo ci si assicura che gli eventuali pezzi mancanti vengano individuati già nelle prime fasi, a differenza di quando il nuovo flusso di lavoro viene progettato in autonomia da un consulente o da un esperto.

D'altra parte, utilizzare un team pilota significa dedicare più tempo alla formazione e alla configurazione iniziali: invece di uno sviluppatore che escogita un nuovo flusso di lavoro, c'è un intero team che potrebbe potenzialmente essere temporaneamente meno produttivo mentre è impegnato ad abituarsi al nuovo flusso di lavoro. Tuttavia, vale assolutamente la pena sopportare questi fastidi a breve termine per ottenere migliori risultati nel lungo termine.

Sicurezza e autorizzazioni

Il controllo degli accessi è un aspetto di Git che richiede di rivoluzionare la modalità di gestione della base di codice.

In SVN, di solito si memorizza l'intera base di codice in un unico repository centrale, quindi si limita l'accesso a diversi team o singole persone in base alla cartella. In Git, questo non è possibile: gli sviluppatori devono recuperare l'intero repository per poterci lavorare. In genere non è possibile recuperare un sottoinsieme del repository, come con SVN. Le autorizzazioni possono essere concesse solo a interi repository Git.

Ciò significa che devi suddividere il tuo grande repository SVN monolitico in tanti piccoli repository Git. In realtà abbiamo sperimentato questa procedura in prima persona qui in Atlassian quando il nostro team di sviluppo Jira ha effettuato la migrazione a Git. Tutti i plug-in di Jira erano archiviati in un unico repository SVN, ma dopo la migrazione, ogni plug-in è finito nel proprio repository.

Tieni presente che Git è stato progettato per integrare in modo sicuro i contributi al codice di migliaia di sviluppatori Linux indipendenti, quindi di sicuro prevede un modo per configurare qualsiasi tipo di controllo degli accessi di cui il tuo team ha bisogno. Questo, tuttavia, potrebbe rendere necessario rivedere il ciclo di compilazione.

Se ti preoccupa mantenere le dipendenze tra la nuova raccolta di repository Git, potresti trovare utile aggiungere un livello di gestione delle dipendenze oltre a Git. Tale modello prevede la memorizzazione nella cache dei progetti man mano che questi aumentano di dimensioni, consentendoti quindi di accelerare i tempi di compilazione. Nell'articolo "Git e dipendenze del progetto" è disponibile una lista degli strumenti consigliati per il livello di gestione delle dipendenze per ogni stack tecnologico.

Un repository per ogni sviluppatore

Il cambiamento più grande a cui dovrai adeguarti come sviluppatore è la natura distribuita di Git. Invece di un unico repository centrale, ogni sviluppatore ha la propria copia dell'intero repository. Questo cambia radicalmente le modalità di collaborazione con i colleghi programmatori.

Invece di estrarre un repository SVN con svn checkout e ottenerne una copia di lavoro, devi clonare l'intero repository Git sul computer locale con git clone.

La collaborazione avviene spostando i branch tra i repository con git push, git fetch o git pull. La condivisione in Git avviene di solito a livello di branch, ma può essere effettuata a livello di commit, in modo simile a SVN. Tuttavia in Git, un commit rappresenta l'intero stato del progetto nel suo insieme, anziché le modifiche apportate ai file. Dato che puoi usare i branch sia in Git che in SVN, la differenza importante qui è che puoi eseguire il commit in locale con Git, senza condividere il tuo lavoro. Ciò ti consente di sperimentare più liberamente, lavorare in modo più efficace offline e velocizza quasi tutti i comandi relativi al controllo delle versioni.

Tuttavia, è importante comprendere che un repository remoto non è un collegamento diretto al repository di qualcun altro. È semplicemente un segnalibro che ti evita di dover digitare nuovamente l'URL completo ogni volta che interagisci con un repository remoto. Finché non esegui esplicitamente un pull o un push di un branch in un repository remoto, lavori in un ambiente isolato.

L'altro grande cambiamento per gli utenti di SVN è la nozione di repository "locali" e "remoti". I repository locali si trovano sul computer locale, mentre tutti gli altri repository sono chiamati repository remoti. Lo scopo principale di un repository remoto è rendere il tuo codice accessibile al resto del team, e quindi al suo interno non avviene nessuna operazione di sviluppo attivo. I repository locali risiedono sul computer locale e al loro interno si svolgono tutte le operazioni di sviluppo del software.

Non aver paura della creazione di branch o del merge

In SVN, si esegue il commit del codice modificando i file nella propria copia di lavoro ed eseguendo quindi svn commit per inviare il codice al repository centrale. Tutti gli altri sviluppatori possono quindi eseguire un pull di queste modifiche nelle proprie copie di lavoro con svn update. I branch di SVN sono generalmente riservati agli elementi di grandi dimensioni e di lunga esecuzione di un progetto, perché il merge è una procedura pericolosa che potrebbe danneggiare il progetto.

Il flusso di lavoro di sviluppo di base di Git è molto diverso. Invece di essere legato a un'unica linea di sviluppo (ad esempio, trunk/), il ciclo di vita ruota attorno alla creazione di branch e al merge.

Quando vuoi iniziare a lavorare in Git, crei ed estrai un nuovo branch con git checkout -b . Con questo comando ottieni una linea di sviluppo dedicata in cui puoi scrivere codice senza preoccuparti di influire sul lavoro degli altri membri del team. Se danneggi qualcosa in modo irreparabile, basta eliminare il branch con il comando git branch -d . Se invece compili qualcosa di utile, presenti una richiesta di pull chiedendo di eseguirne il merge nel branch principale.

Potenziali flussi di lavoro Git

Quando si sceglie un flusso di lavoro Git è importante tenere presenti le esigenze del team. Un flusso di lavoro semplice può massimizzare la velocità e la flessibilità dello sviluppo, mentre un flusso di lavoro più complesso può garantire maggiore coerenza e controllo del lavoro in corso. Puoi adattare e combinare gli approcci generali elencati di seguito in base alle esigenze e ai diversi ruoli del tuo team. Ad esempio, lo sviluppatore principale potrebbe utilizzare i branch di funzioni, mentre i collaboratori esterni lavorano da un fork.

• Un flusso di lavoro centralizzato è l'opzione più simile ai processi SVN più comuni, quindi è un buon punto di partenza.
• Partendo da questa idea, l'utilizzo di un flusso di lavoro del branch di funzioni consente agli sviluppatori di mantenere isolato il lavoro in corso e protetti i branch condivisi importanti. I branch di funzioni costituiscono anche la base per la gestione delle modifiche tramite pull request.
• Un flusso di lavoro Gitflow è un'estensione più formale e strutturata della creazione di branch di funzioni, il che la rende un'ottima opzione per i team di maggiori dimensioni con cicli di rilascio ben definiti.
• Infine, prendi in considerazione il flusso di lavoro di fork se hai bisogno del massimo isolamento e controllo sulle modifiche o se vi sono molti sviluppatori che contribuiscono a un repository.

Ma se vuoi davvero ottenere il massimo da Git come team di professionisti, dovresti prendere in considerazione il flusso di lavoro del branch di funzioni. Si tratta di un flusso di lavoro realmente distribuito e assolutamente sicuro, incredibilmente scalabile e Agile per antonomasia.

La transizione del team a Git può presentare delle difficoltà, ma non deve essere obbligatoriamente un compito arduo. In questo articolo sono state descritte alcune delle opzioni più comuni per la migrazione della base di codice esistente, l'implementazione di Git nei team di sviluppo e la gestione della sicurezza e delle autorizzazioni. Sono state inoltre presentate le maggiori sfide a cui gli sviluppatori dovrebbero essere preparati durante il processo di migrazione.

Spero che tu ora abbia una solida base per introdurre lo sviluppo distribuito nella tua azienda, indipendentemente dalle sue dimensioni o dalle pratiche di sviluppo attuali.