Per i team di sviluppo software Agile e DevOps, Git è il sistema di controllo delle versioni de facto e una parte essenziale di una toolchain DevOps. Questo progetto open source adeguatamente supportato offre una flessibilità sufficiente per supportare una gamma di flussi di lavoro adatti alle esigenze di qualsiasi team software. La sua natura distribuita, piuttosto che centralizzata, gli conferisce prestazioni superiori e offre agli sviluppatori la libertà di sperimentare localmente e di pubblicare le proprie modifiche solo quando sono pronti per la distribuzione al team.
Oltre ai vantaggi della flessibilità e della distribuzione, Git offre alcune funzioni chiave che supportano e migliorano i team di sviluppo Agile e DevOps. Git può essere immaginato come un componente dello sviluppo Agile e DevOps: le modifiche possono essere inviate alla pipeline di distribuzione più velocemente rispetto all'utilizzo di rilasci monolitici e sistemi di controllo delle versioni centralizzati. Git funziona nello stesso modo in cui i tuoi team Agile e DevOps lavorano (o dovrebbero lavorare).
Suggerimento 1: inizia a pensare ai task come branch Git
Git entra in gioco dopo che le funzioni sono state sviluppate e aggiunte a una roadmap di prodotto, e il team di sviluppo è pronto. Ma facciamo un passo indietro per un rapido corso accelerato sullo sviluppo delle funzioni Agile: i team di prodotto, progettazione, controllo di qualità e ingegneria conducono un meeting introduttivo sulle funzioni allo scopo di ottenere una comprensione condivisa di quali saranno le caratteristiche di una funzione (cioè i requisiti), l'ambito del progetto e i task in cui la funzione deve essere suddivisa per essere completata. Questi task, noti anche come storie utente, vengono quindi assegnati ai singoli sviluppatori.
Git inizia a inserirsi nel tuo flusso di lavoro Agile in questo punto. In Atlassian, creiamo un nuovo branch per ogni singolo ticket. Che si tratti di una nuova funzione, di una correzione di bug o di un piccolo miglioramento a un codice esistente, ogni modifica del codice ha il proprio branch.
La creazione di branch è intuitiva e consente ai team di collaborare facilmente all'interno di una base del codice centrale. Quando uno sviluppatore crea un branch, dispone effettivamente di una propria versione isolata della base del codice in cui apportare le modifiche. Per un team Agile questo significa che, suddividendo le funzioni in storie utente e quindi in branch, il team di sviluppo ha la possibilità di affrontare i singoli task e di lavorare in modo più efficiente sullo stesso codice ma in repository diversi; non è presente alcuna duplicazione del lavoro e, poiché le persone possono concentrarsi su piccoli elementi di lavoro in repository separati rispetto al repository principale, le dipendenze che rallentano il processo di sviluppo non sono numerose.
Oltre alla creazione di branch dei task esistono altri tipi di creazione di branch Git, che non si escludono a vicenda. Puoi creare, ad esempio, branch per un rilascio. Questo consente agli sviluppatori di stabilizzare e rafforzare il lavoro programmato per un rilascio specifico, senza ostacolare altri sviluppatori che stanno lavorando ai rilasci futuri.
Dopo aver creato un branch di rilascio, dovrai eseguirne regolarmente il merge nel tuo branch principale per assicurarti che la tua funzione sia disponibile nei rilasci futuri. Per ridurre al minimo il sovraccarico, è preferibile creare il branch di rilascio il più vicino possibile alla data di rilascio programmata.
Suggerimento 2: è possibile testare singolarmente più branch, quindi approfittane
Una volta che i branch sono considerati completati e pronti per le revisioni del codice, Git svolge un altro ruolo chiave in un flusso di lavoro di sviluppo Agile: i team Agile e DevOps efficaci conducono le revisioni del codice e configurano test automatizzati (continuous integration o continuous delivery). Per facilitare le revisioni e i test del codice, gli sviluppatori possono facilmente informare il resto del team che il lavoro del branch è pronto per la revisione e deve essere rivisto tramite una pull request. Più semplicemente, una pull request rappresenta un modo per chiedere a un altro sviluppatore di eseguire il merge di uno dei tuoi branch nel branch principale e di indicare è pronto per i test.
Con gli strumenti giusti, il tuo server di continuous integration può creare e testare le pull request prima di effettuarne il merge. In questo modo hai la certezza che il merge non causerà problemi e, in generale, diventa più facile ridefinire la destinazione delle correzioni di bug e dei conflitti, perché Git conosce la differenza tra il branch e la base del codice principale poiché i branch sono divergenti.
Un branch di funzioni a esecuzione prolungata che non viene unito al branch principale può danneggiare la tua capacità di essere Agile e iterare. Se hai un branch di funzioni a esecuzione prolungata, ricorda che hai effettivamente due versioni divergenti della base del codice, il che comporterà un maggior numero di correzioni di bug e conflitti. Tuttavia, la soluzione migliore è avere branch di funzioni di breve durata. Ciò può essere ottenuto attraverso una scomposizione delle storie utente in task più piccoli, un'attenta pianificazione degli sprint e il merge tempestivo del codice affinché venga rilasciato come funzioni nascoste.
Suggerimento 3: Git fornisce trasparenza e qualità allo sviluppo Agile
La story Git/Agile riguarda l'efficienza, i test, l'automazione e l'agilità generale. Dopo aver eseguito il merge di un branch al branch principale, il flusso di lavoro Agile è terminato. Allo stesso modo, il merge del codice effettuato tramite pull request significa che quando il codice è completato, hai la documentazione necessaria per sapere con certezza che il tuo lavoro è verde, che altri membri del team hanno approvato il codice e che questo è pronto per il rilascio. Ciò consente ai team Agile di agire in modo veloce e sicuro per effettuare rilasci frequenti: la caratteristica che contraddistingue un team Agile eccellente.
L'adozione di una cadenza di rilascio regolare è fondamentale per lo sviluppo Agile. Affinché Git funzioni per il tuo flusso di lavoro Agile, devi assicurarti che il tuo branch principale Agile sia sempre verde. Ciò significa che se una funzione non è pronta, devi attendere il rilascio successivo. Se pratichi cicli di rilascio più brevi ciò non dovrebbe costituire un grosso problema.
