Eseguire la migrazione a Git dal controllo della versione centralizzato

Articolo
08/26/2023

La migrazione di un team a Git dal controllo della versione centralizzato richiede più di apprendere nuovi comandi. Per supportare lo sviluppo distribuito, Git archivia le informazioni sulla cronologia dei file e sui rami in modo diverso rispetto a un sistema di controllo della versione centralizzato. La pianificazione e l'implementazione di una migrazione corretta a Git da un sistema di controllo della versione centralizzato richiede la comprensione di queste differenze fondamentali.

Microsoft ha aiutato a eseguire la migrazione di molti team interni e clienti da sistemi di controllo della versione centralizzati a Git. Questa esperienza ha prodotto le indicazioni seguenti in base alle procedure che hanno successo in modo coerente.

Passaggi per la corretta migrazione

Per una migrazione corretta, i team devono:

Valutare gli strumenti e i processi correnti.
Selezionare una strategia di diramazione Git.
Decidere se e come eseguire la migrazione della cronologia.
Mantenere il sistema di controllo della versione precedente.
Rimuovere file binari, eseguibili e strumenti dal controllo del codice sorgente.
Eseguire il training di team in concetti e procedure Git.
Testare la migrazione a Git.

Valutare gli strumenti e i processi correnti

La modifica dei sistemi di controllo della versione interrompe naturalmente il flusso di lavoro di sviluppo con nuovi strumenti e procedure. Questa interruzione può essere un'opportunità per migliorare altri aspetti del processo DevOps.

I team devono prendere in considerazione l'adozione delle procedure seguenti durante la migrazione al nuovo sistema:

Integrazione continua (CI), in cui ogni archiviazione attiva un passaggio di compilazione e test. L'integrazione continua aiuta a identificare i difetti in anticipo e fornisce una rete di sicurezza avanzata per i progetti.
Revisioni del codice necessarie prima di controllare il codice. Nel modello di diramazione Git, la revisione del codice della richiesta pull fa parte del processo di sviluppo. Le revisioni del codice integrano il flusso di lavoro ci.
Recapito continuo (CD) per automatizzare i processi di distribuzione. La modifica degli strumenti di controllo della versione richiede modifiche al processo di distribuzione, pertanto una migrazione è un buon momento per adottare una pipeline di versione moderna.

Selezionare una strategia di diramazione Git

Prima di eseguire la migrazione del codice, il team deve selezionare una strategia di diramazione.

In Git, i rami di argomenti di breve durata consentono agli sviluppatori di lavorare vicino al ramo principale e di integrarsi rapidamente, evitando problemi di merge. Due strategie di ramo di argomenti comuni sono GitFlow e una variante più semplice, GitHub Flow.

Git sconsiglia i rami di funzionalità isolati e di lunga durata, che tendono a ritardare le unioni fino a quando l'integrazione non diventa difficile. Usando tecniche di distribuzione continua moderne come i flag di funzionalità, i team possono integrare rapidamente il codice nel ramo principale, ma mantenere le funzionalità in corso nascoste agli utenti fino a quando non vengono completate.

I team che attualmente usano una strategia di ramo di funzionalità di lunga durata possono adottare flag di funzionalità prima della migrazione a Git. L'uso dei flag di funzionalità semplifica la migrazione riducendo al minimo il numero di rami di cui eseguire la migrazione. Indipendentemente dal fatto che usino rami di funzionalità o flag di funzionalità, i team devono documentare il mapping tra rami legacy e nuovi rami Git, in modo che tutti comprendano dove eseguire il commit del nuovo lavoro.

Decidere se eseguire la migrazione della cronologia

Teams potrebbe essere tentato di eseguire la migrazione della cronologia del codice sorgente esistente a Git. Diversi strumenti sostengono di eseguire la migrazione di una cronologia completa di tutti i rami da uno strumento centralizzato a Git. Un commit Git sembra mappare relativamente bene al set di modifiche o al modello di archiviazione usato dallo strumento di controllo della versione precedente.

Tuttavia, questo mapping presenta alcune limitazioni gravi.

Nella maggior parte dei sistemi di controllo della versione centralizzati, i rami esistono come cartelle nel repository. Ad esempio, il ramo principale potrebbe essere una cartella denominata /trunk e altri rami sono cartelle come /branch/one e /branch/two. In un repository Git i rami includono l'intero repository, quindi una traduzione 1:1 è difficile.
In alcuni sistemi di controllo della versione, un tag o un'etichetta è una raccolta che può contenere vari file nell'albero, anche i file in versioni diverse. In Git un tag è uno snapshot dell'intero repository in un momento specifico. Un tag non può rappresentare un subset del repository o combinare file in versioni diverse.
La maggior parte dei sistemi di controllo della versione archivia i dettagli sul modo in cui i file cambiano tra le versioni, tra cui tipi di modifica con granularità fine, ad esempio rinomina, annullamento dell'eliminazione e rollback. Git archivia le versioni come snapshot dell'intero repository e i metadati relativi al modo in cui i file modificati non sono disponibili.

Queste differenze indicano che una migrazione completa della cronologia andrà persa nel migliore dei casi e probabilmente fuorviante. Data la perdita, l'impegno richiesto e la rarità relativa dell'uso della cronologia, è consigliabile che la maggior parte dei team eviti di importare la cronologia. Al contrario, i team devono eseguire una migrazione con mancia, portando solo uno snapshot della versione più recente del ramo in Git. Per la maggior parte dei team, il tempo è meglio dedicato alle aree della migrazione che hanno un maggiore ritorno sugli investimenti, ad esempio il miglioramento dei processi.

Gestire il sistema di controllo della versione precedente

Durante e dopo una migrazione, gli sviluppatori potrebbero comunque dover accedere alla cronologia del controllo della versione precedente. Anche se la cronologia del controllo della versione precedente diventa meno rilevante nel tempo, è comunque importante essere in grado di farvi riferimento. Gli ambienti altamente regolamentati potrebbero avere requisiti legali e di controllo specifici per la cronologia del controllo della versione.

Soprattutto per i team che eseguono solo una migrazione con mancia, è consigliabile mantenere il sistema precedente per un periodo illimitato. Impostare il sistema di controllo della versione precedente su sola lettura dopo la migrazione.

I team di sviluppo di grandi dimensioni e gli ambienti regolamentati possono inserire percorsi di navigazione in Git che rimandano al sistema di controllo della versione precedente. Un semplice esempio è un file di testo aggiunto come primo commit nella radice di un repository Git, prima della migrazione della mancia, che punta all'URL del server di controllo della versione precedente. Se viene eseguita la migrazione di molti rami, un file di testo in ogni ramo deve spiegare come i rami migrati dal sistema precedente. I percorsi di navigazione sono utili anche per gli sviluppatori che iniziano a lavorare su un progetto dopo la migrazione e non hanno familiarità con il sistema di controllo della versione precedente.

Rimuovere file binari e strumenti

Il modello di archiviazione di Git è ottimizzato per il controllo delle versioni dei file di testo e del codice sorgente, che sono compatta e altamente compressi. I file binari sono in genere di grandi dimensioni e, una volta aggiunti a un repository, rimangono nella cronologia del repository e in ogni clone futuro. A causa del modo in cui Git archivia la cronologia, gli sviluppatori devono evitare di aggiungere file binari ai repository, in particolare i file binari molto grandi o che cambiano spesso. La migrazione a Git è un'opportunità per rimuovere questi file binari dalla codebase.

È anche consigliabile escludere librerie, strumenti e output di compilazione dai repository. Usare invece sistemi di gestione dei pacchetti come NuGet per gestire le dipendenze.

Gli asset come icone e immagini potrebbero dover essere allineati a una versione specifica del codice sorgente. Gli asset piccoli e modificati raramente come le icone non bloat history e possono essere inclusi direttamente in un repository. Per archiviare asset di grandi dimensioni o di modifica frequente, usare l'estensione Git Large File Archiviazione (LFS). Per altre informazioni sulla gestione di file di grandi dimensioni in GitHub, vedere Gestione di file di grandi dimensioni. Per Azure Repos, vedere Gestire e archiviare file di grandi dimensioni in Git.

Fornire il training

Una delle principali sfide della migrazione a Git è aiutare gli sviluppatori a comprendere in che modo Git archivia le modifiche e come esegue il commit della cronologia di sviluppo dei moduli. Non è sufficiente preparare un foglio informativo che esegue il mapping dei comandi precedenti ai comandi Git. Gli sviluppatori devono smettere di pensare alla cronologia del controllo della versione in termini di un modello centralizzato, lineare e comprendere il modello di cronologia di Git e il grafico di commit.

Persone imparare in modi diversi, quindi è necessario fornire diversi tipi di materiali di formazione. La formazione basata su laboratorio con un insegnante esperto funziona bene per alcune persone. Il libro Pro Git è un ottimo punto di partenza disponibile online.

I corsi di formazione pratici disponibili includono:

Le organizzazioni devono lavorare per identificare gli esperti Git in team, consentire loro di aiutare gli altri utenti e incoraggiare altri membri del team a porre domande.

Test della migrazione

Dopo che i team aggiornano i processi, analizzano il codice ed eseguono il training dei membri, è il momento di eseguire la migrazione del codice sorgente. Indipendentemente dalla migrazione o dalla cronologia di migrazione dei suggerimenti, è importante eseguire una o più migrazioni di test in un repository di test. Prima di eseguire una migrazione finale, assicurarsi di:

Eseguire la migrazione di tutti i file di codice.
Tutti i rami sono disponibili.
Nel repository non sono presenti file binari strani.
Gli utenti hanno le autorizzazioni appropriate per recuperare ed eseguire il push.
Le compilazioni hanno esito positivo e tutti i test vengono superati.

Eseguire la migrazione del codice

Eseguire la migrazione finale durante le ore non lavorative, idealmente tra le attività cardine quando si verifica un tempo di inattività naturale. La migrazione alla fine di uno sprint potrebbe causare problemi mentre gli sviluppatori tentano di completare il lavoro. Provare a eseguire la migrazione durante un fine settimana, quando nessuno deve eseguire l'archiviazione.

Pianificare un cutover aziendale dal sistema di controllo della versione precedente a Git. Il tentativo di gestire più sistemi in parallelo significa che gli sviluppatori potrebbero non sapere dove o come eseguire l'archiviazione. Impostare il sistema di controllo della versione precedente su sola lettura per evitare confusione. Senza questa protezione, potrebbe essere necessaria una seconda migrazione che include modifiche provvisorie.

Il processo di migrazione effettivo varia a seconda del sistema da cui si esegue la migrazione. Per informazioni sulla migrazione da controllo della versione di Team Foundation, vedere Eseguire la migrazione da TFVC a Git.

Elenco di controllo per la migrazione

Flussi di lavoro del team:

Determinare la modalità di esecuzione delle compilazioni.
Decidere quando verranno eseguiti i test.
Sviluppare un processo di gestione delle versioni.
Spostare le revisioni del codice nelle richieste pull.

Strategia di diramazione:

Selezionare una strategia di diramazione Git.
Documentare la strategia di diramazione, il motivo per cui è stata selezionata e il mapping dei rami legacy.

Cronologia:

Decidere per quanto tempo mantenere in esecuzione il controllo della versione legacy.
Identificare i rami di cui è necessario eseguire la migrazione.
Se necessario, creare percorsi di navigazione per consentire ai tecnici di tornare al sistema legacy.

File binari e strumenti:

Identificare i file binari e i file non individuabili da rimuovere dal repository.
Decidere un approccio per file di grandi dimensioni, ad esempio Git-LFS.
Decidere un approccio per distribuire strumenti e librerie, ad esempio NuGet.

Training:

Identificare i materiali di formazione.
Pianificare eventi di formazione, materiali scritti e video.
Identificare i membri del team da usare come esperti Git locali.

Migrazione del codice:

Eseguire più esecuzioni di test per assicurarsi che la migrazione andrà senza problemi.
Identificare e comunicare un tempo di cutover.
Creare il nuovo repository Git.
Impostare il sistema precedente su sola lettura.
Eseguire prima di tutto la migrazione del ramo principale, quindi qualsiasi altro ramo necessario.