Scegliere una strategia per il flusso del codice
È importante scegliere una strategia di flusso del codice adatta alla modalità di lavoro del team. Ci sono diverse strategie da considerare. Alla fine del modulo è possibile esplorare le opzioni. Il team Web di Tailspin decide di sviluppare una strategia di flusso del codice basata su Git e GitHub.
Quando Mara ha configurato Azure Boards, lei e il team hanno identificato alcune attività iniziali da risolvere. Una delle attività era la creazione di un flusso di lavoro basato su Git.
Ecco il team al lavoro per trovare un modo migliore per collaborare. Attualmente il team usa un sistema di controllo della versione centralizzato, ma il piano prevede lo spostamento in Git, un sistema distribuito.
Mara sta lavorando diligentemente alle funzionalità che le sono state assegnate quando Andy si avvicina.
Andy: Ciao, Mara. Dalla riunione dei dirigenti di questa mattina è emerso che il nostro team e il team di sviluppo dei giochi usano sistemi di controllo della versione diversi. Per semplificare la condivisione delle risorse tra team, ci è stato chiesto di passare a un sistema di controllo della versione distribuito che possa gestire meglio la collaborazione.
Mara: È una bella notizia. Se ricordi, lo abbiamo inserito sulla lavagna. Attualmente usiamo un sistema di controllo della versione centralizzato. È un'ottima soluzione per il momento, ma riconosco che un sistema di controllo della versione distribuito è la scelta migliore quando si inizia a condividere contenuti tra team e il nostro team si allarga. Sulla lavagna è segnata anche un'attività finalizzata ad aumentare la visibilità, in modo che tutte le persone coinvolte sappiano cosa stanno facendo gli altri. Credo che anche un sistema di controllo del codice sorgente distribuito come Git possa essere utile.
Andy: È da molto che voglio provare Git. ma non ne ho mai avuto il tempo. È difficile da apprendere o configurare? Se ti sembra ragionevole, potremmo lavorarci adesso. Sono stanco di posticipare sempre. Inoltre, sarebbe bello vedere cosa fanno tutti gli altri e avere accesso all'intero repository. Di cosa si tratta?
Mara: Lascia che te lo spieghi e poi potrai decidere se implementarlo subito o meno.
Mara e Andy passano alla lavagna per una discussione sul controllo della versione.
Che cosa sono Git e il controllo della versione distribuito?
Mara: Il disegno a sinistra rappresenta il controllo della versione centralizzato, come quello che usiamo attualmente. È presente una versione centrale della codebase 
nel controllo della versione di Team Foundation usata da tutti. Ognuno lavora sui file che è necessario modificare e quindi li unisce di nuovo al repository principale al termine.
Andy: Sì, e questo funziona per noi. Ad eccezione di quella volta in cui sono rimasto bloccato quando nel repository centrale è stato eseguito il merge di una modifica che ha causato un'interruzione.
Mara: Esatto. L'operazione è stata bloccata 
. Potremmo usare una strategia di creazione di rami con il controllo della versione di Team Foundation per risolvere il problema che causa un blocco, ma nella configurazione corrente l'unione potrebbe risultare più complessa. Inoltre, quando abbiamo apportato quella modifica che ha causato un'interruzione 
nessuno ha potuto eseguire alcuna operazione fino a quando non è stata risolta. Questo problema è sempre in agguato, perché usiamo tutti la stessa copia del codice.
Sulla destra è presente un disegno del controllo della versione distribuito. È ancora presente un repository centrale 
che rappresenta la versione stabile della codebase, ma ogni sviluppatore ne ha una propria copia 
da usare. Questo ci consente di sperimentare e provare diversi approcci senza influire sul repository centrale.
Il controllo della versione distribuito garantisce anche che nel repository centrale venga eseguito il merge solo del codice funzionante 
. È anche possibile configurarlo in modo da impedire il merge del codice finché non viene esaminato.
L'aspetto interessante di Azure DevOps è che funziona bene sia con i sistemi di controllo della versione centralizzati sia con quelli distribuiti.
Andy: Cosa accade quando più persone modificano lo stesso file?
Mara: Spesso Git è in grado di eseguire il merge di più modifiche automaticamente. Naturalmente, è necessario assicurarsi sempre che la combinazione delle modifiche crei codice funzionante. Quando Git non può eseguire automaticamente il merge delle modifiche, contrassegna i conflitti direttamente nei file, in modo che l'utente possa scegliere le modifiche da accettare.
Andy: Al momento, il codice viene archiviato nel nostro server. Se si passa al controllo della versione distribuito, dove verrà archiviato il codice?
Mara: Ottima domanda. È qui che entra in gioco l'hosting.
Dove è possibile ospitare il repository?
Mara: Quando decidiamo dove ospitare i nostri repository, abbiamo alcune opzioni. Ad esempio, possiamo ospitarli in un server locale, in Bitbucket o in GitHub. Bitbucket e GitHub sono soluzioni host basate sul Web. È possibile accedervi ovunque ci si trovi.
Andy: Li hai mai usati?
Mara: In passato ho usato GitHub. Include funzionalità importanti per gli sviluppatori, ad esempio un accesso facile ai log delle modifiche e funzionalità di controllo della versione dalla riga di comando o dal portale online.
Andy: Dunque, come funziona Git?
Come si usa?
Mara: Come ho detto in precedenza, con i sistemi distribuiti gli sviluppatori sono liberi di accedere ai file necessari senza influire sul lavoro di altri sviluppatori, perché hanno una propria copia del repository. Un clone è la copia locale di un repository.
Quando lavoriamo a una funzionalità o alla correzione di bug, in genere preferiamo provare diversi approcci fino a trovare la soluzione migliore. Non è tuttavia consigliabile provare il codice sulla propria copia della codebase principale, perché potrebbe non essere opportuno conservare i primi tentativi.
Per offrire un'opzione migliore, Git include una funzionalità denominata diramazione, che permette di mantenere il numero di copie desiderato ed eseguire di nuovo il merge solo di quelle da mantenere. In questo modo si mantiene stabile il ramo principale.
Andy: Finora è tutto chiaro. Come faccio a controllare il codice?
In che modo le modifiche locali vengono apportate alla codebase principale?
Mara: in Git, il ramo predefinito, o trunk, viene in genere denominato main.
Quando si ritiene che il codice sia pronto per il merge nel ramo main del repository centrale condiviso da tutti gli sviluppatori, si crea quella che viene definita richiesta pull. Quando si crea una richiesta pull, si comunica agli altri sviluppatori che il codice è pronto per la revisione e che si vuole eseguirne il merge nel ramo main. Quando la richiesta pull viene approvata e sottoposta a merge, entra a far parte della codebase centrale.
Che aspetto ha un flusso di lavoro di diramazione?
Passaggio 1: quando si inizia a lavorare a una nuova funzionalità o a una correzione di bug, è prima di tutto necessario verificare di iniziare con la codebase stabile più recente. A tale scopo, è possibile sincronizzare la copia locale del ramo main con la copia del server. In questo modo, viene eseguito il pull nella copia locale di tutte le modifiche apportate da altri sviluppatori che sono state sottoposte a push nel ramo main sul server dall'ultima sincronizzazione.
Passaggio 2: per assicurarsi di lavorare in tutta sicurezza sulla propria copia del codice, creare un nuovo ramo solo per la funzionalità o la correzione di bug. Come si può immaginare, molti rami per tutte le attività in corso potrebbero essere difficili da ricordare, quindi l'uso di una corretta convenzione di denominazione è fondamentale.
Prima di apportare modifiche a un file, è necessario estrarre un nuovo ramo in modo da essere certi di lavorare sui file di tale ramo e non di un ramo diverso. È possibile cambiare ramo in qualsiasi momento eseguendo il checkout di tale ramo.
Passaggio 3: ora è possibile apportare tutte le modifiche desiderate, perché queste si trovano solo nel proprio ramo. Quando si lavora, è possibile eseguire il commit delle modifiche nel ramo per assicurarsi di non perdere alcun lavoro e offrire un modo per eseguire il rollback delle modifiche apportate alle versioni precedenti. Prima di poter eseguire il commit delle modifiche, è necessario preparare per il commit i file in modo che Git sappia quali sono pronti per il commit.
Passaggio 4: il passaggio successivo consiste nel push, o caricamento, del ramo locale fino al repository remoto, ad esempio GitHub, in modo che altri utenti possano vedere a cosa si sta lavorando. Non è ancora necessario eseguire il merge delle modifiche. È possibile eseguire il push del lavoro con la frequenza desiderata. In realtà, si tratta di un metodo efficace per eseguire il backup del lavoro o consentire l'uso di più computer.
Passaggio 5: anche se comune, questo passaggio non è obbligatorio. Quando si è soddisfatti e il codice funziona come si desidera, è possibile eseguire il pullo il merge del ramo remoto main nel ramo locale main. Sono state apportate modifiche che non sono ancora presenti nel ramo main locale. Dopo aver sincronizzato il ramo main remoto con il proprio, unire il ramo main locale con il ramo di lavoro e testare di nuovo la compilazione.
Questo processo garantisce che la funzionalità funzioni con il codice più recente, oltre ad assicurare che il lavoro venga integrato senza problemi quando si invia la richiesta pull.
Passaggio 6: è ora necessario eseguire il commit e il push del codice locale nel repository ospitato. Questa procedura corrisponde ai passaggi 3 e 4.
Passaggio 7: si è finalmente pronti per proporre le modifiche al ramo main remoto. A tale scopo, viene avviata una richiesta pull. Quando è configurato in Azure Pipelines o in un altro sistema CI/CD, questo passaggio attiva il processo di compilazione ed è possibile osservare il flusso delle modifiche attraverso la pipeline. Dopo il completamento della compilazione e la ricezione dell'approvazione della richiesta pull da parte di altri utenti, è possibile eseguire il merge del codice al ramo main remoto. Il merge delle modifiche deve sempre essere eseguito dall'utente.
Andy: Questa procedura sembra complessa e difficile da apprendere.
Mara: Git può sembrare complesso perché è così potente, ma quando si impara a usare il flusso, tutto risulta più facile.
Verranno usati solo alcuni comandi ogni giorno. Di seguito è disponibile un riepilogo:
| Categoria | Per eseguire questa attività | Usare questo comando |
|---|---|---|
| Gestione del repository | Creare un repository Git | git init |
| Scaricare un repository remoto | git clone |
|
| Filiale | Creare un ramo | git checkout |
| Preparare ed eseguire il commit delle modifiche | Vedere quali file sono stati modificati | git status |
| Preparare per il commit i file | git add |
|
| Eseguire il commit dei file nel ramo | git commit |
|
| Sincronizzazione remota | Scaricare un ramo da un repository remoto | git pull |
| Caricare un ramo in un repository remoto | git push |
Andy: Mi sembra un ottimo punto di partenza. Sono sicuramente in grado di farcela. Potrò apprendere altri comandi avanzati, se necessario.