Condividi tramite

Eseguire la migrazione a Git dal controllo della versione centralizzato

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.
  • Formare i team sui concetti e le pratiche di 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 commit 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 moderne tecniche di distribuzione continua come i flag di funzionalità, i team possono integrare rapidamente il codice nel ramo principale, mantenendo tuttavia nascoste agli utenti le funzionalità in corso fino al loro completamento.

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 da migrare. 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

I team potrebbero essere tentati di migrare la cronologia esistente del codice sorgente su Git. Diversi strumenti sostengono di eseguire la migrazione di una cronologia completa di tutti i rami da uno strumento centralizzato a Git. Il commit Git sembra corrispondere abbastanza bene al modello di changeset o di check-in utilizzato dallo strumento di controllo 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 sarà imprecisa nel migliore dei casi e potenzialmente 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 dovrebbero eseguire una migrazione della punta, portando solo uno snapshot dell'ultima versione 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 puntuale, è altamente consigliabile mantenere il sistema precedente indefinitamente. 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 i "breadcrumbs" in Git che rimandano al sistema di controllo della versione precedente. Un semplice esempio è un file di testo aggiunto come primo commit alla radice di un repository Git, prima della migrazione della punta, 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. Le briciole di pane sono utili anche per gli sviluppatori che iniziano a lavorare su un progetto dopo la migrazione e non sono familiari con il vecchio sistema di version control.

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, come le icone, che vengono modificati raramente, non appesantiscono la cronologia e possono essere inclusi direttamente in un repository. Per archiviare asset di grandi dimensioni o di modifica frequente, usare l'estensione Git Large File Storage (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 formazione

Una delle sfide più grandi della migrazione a Git è aiutare gli sviluppatori a comprendere in che modo Git memorizza le modifiche e come i commit formano la cronologia di sviluppo. Non è sufficiente preparare una scheda di riferimento che mappa i 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.

Le persone imparano in modi diversi, quindi è consigliabile 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 del 'tip' o dalla migrazione della cronologia, è importante eseguire una o più migrazioni di prova in un repository di prova. 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. Cercare di eseguire la migrazione durante un fine settimana, quando nessuno deve segnare la presenza.

Pianificare un definitivo passaggio dal vecchio sistema di controllo delle versioni a Git. Tentare di gestire più sistemi contemporaneamente significa che gli sviluppatori possono non sapere dove o come effettuare un commit. 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 dal 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 come verranno eseguiti i build.
  • Decidere quando verranno eseguiti i test.
  • Sviluppare un processo di gestione delle versioni.
  • Spostare le revisioni del codice sulle pull request.

Strategia di diramazione:

  • Selezionare una strategia di diramazione Git.
  • Documentare la strategia di diramazione, il motivo per cui è stata scelta e come sono mappati i rami legacy.

History:

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

Formazione:

  • 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 l'orario di passaggio a un nuovo sistema.
  • Creare il nuovo repository Git.
  • Impostare il vecchio sistema su sola lettura.
  • Eseguire prima di tutto la migrazione del ramo principale, quindi qualsiasi altro ramo necessario.

Passaggi successivi

  • Last updated on