Scegliere una strategia per il flusso del codice
- 8 minuti
È 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: È bello saperlo. 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: Volevo provare Git per un po'. 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: Lasciate che lo spieghi, e poi si può decidere se sembra qualcosa che vogliamo implementare subito.
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 è controllo di versione centralizzato, come quello che stiamo usando ora. È 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 sta lavorando 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: Giusto! 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.
A destra è riportato un disegno di controllo della versione distribuita. È 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 può unire automaticamente più modifiche. 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 proprio server. Se si passa al controllo della versione distribuito, dove verrà archiviato il codice?
Mara: Sono contento che ti abbia chiesto. È qui che entra in gioco l'hosting.
Dove è possibile ospitare il repository?
Mara: Quando si decide dove ospitare i repository, sono disponibili 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: Hai usato uno di loro?
Mara: Ho usato GitHub in passato. 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: Come funziona Git?
Come si usa?
Mara: Come accennato in precedenza, con i sistemi distribuiti, gli sviluppatori sono liberi di accedere a qualsiasi file di cui hanno bisogno senza influire sul lavoro di altri sviluppatori perché hanno la 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 ha una funzionalità denominata diramazione, in cui è possibile mantenere il numero di copie desiderate e unire di nuovo solo quella che si vuole mantenere. In questo modo si mantiene stabile il ramo principale.
Andy: Ho capito i concetti finora. 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 chiamato main.
Quando si ritiene che il codice sia pronto per essere unito al main ramo nel repository centrale condiviso da tutti gli sviluppatori, si crea una 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 su una nuova funzionalità o correzione di bug, la prima cosa da fare è assicurarsi 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 solo sulla copia del codice, creare un nuovo ramo solo per tale funzionalità o 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: Adesso puoi apportare le modifiche desiderate perché queste modifiche si trovano solo nel tuo ramo. Mentre si lavora, è possibile eseguire il commit delle modifiche nel ramo per assicurarsi di non perdere alcun lavoro. In questo modo è anche possibile 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 eseguire il push o il caricamento del ramo locale fino al repository remoto (ad esempio GitHub) in modo che altri utenti possano visualizzare ciò che 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: questo passaggio è un passaggio comune, ma 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 remoto main . 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: Tutto questo sembra complicato e difficile da imparare.
Mara: Git può sembrare intimidatorio perché è così potente, ma dopo aver preso confidenza con il flusso, ti sembrerà naturale.
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 |
|
| Ramo | 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: Sembra un ottimo punto di partenza. Sono sicuramente in grado di farcela. Potrò apprendere altri comandi avanzati, se necessario.