Quali sono le best practice di GitLab Flow?

Quando un software viene sviluppato di fretta per accelerarne la distribuzione, i flussi di lavoro possono essere caotici e poco efficienti. Le organizzazioni che in precedenza utilizzavano un altro sistema di controllo della versione tendono spesso a trovarsi di fronte a processi impegnativi che rischiano di rallentare lo sviluppo. Grazie a GitLab Flow, i team possono avvalersi dello sviluppo basato sulle funzionalità e dei rami delle funzionalità, insieme al monitoraggio dei ticket, per fare in modo che ogni membro del team garantisca la massima efficienza. Adottando i suggerimenti di GitLab Flow, i team di sviluppo possono semplificare il processo, produrre risultati migliori e scrivere codice in modo più ordinato.

L'utilizzo dei rami delle funzionalità è un modo semplice per sviluppare e mantenere ordinato il codice sorgente. Ad esempio, se un team è passato di recente da SVN a Git, gli sviluppatori saranno già abituati a un flusso di lavoro basato su trunk. Quando si utilizza Git, è necessario creare un ramo per ogni elemento a cui si lavora in modo che i collaboratori possano avviare facilmente il processo di revisione del codice prima di eseguire il merge.

Alcuni sviluppatori configurano il processo di integrazione continua per testare solo gli elementi il cui merge sia stato eseguito al ramo main. Tuttavia, ciò avviene troppo tardi all'interno del ciclo di sviluppo software e tutte le parti in causa, dai programmatori ai product manager, dovrebbero essere sempre sicuri che il ramo main sia stabile e funzioni correttamente. Testare il ramo main prima di iniziare a sviluppare nuove funzionalità non è una pratica efficiente.

Quando lavori su un ramo feature e aggiungi nuovi commit, esegui subito i test. Se i test richiedono molto tempo, prova a eseguirli in parallelo. Effettua questa operazione lato server nelle richieste di merge, eseguendo la suite di test completa. Se disponi di una suite di test per lo sviluppo e di un'altra specifica per le nuove versioni, vale la pena impostare test [in parallelo] ed eseguirli tutti.

Non testare tutti gli elementi alla fine della settimana o al termine di un progetto. Le revisioni del codice devono essere effettuate il prima possibile, in quanto ciò offre agli sviluppatori maggiori probabilità di identificare i ticket che potrebbero causare problemi nelle fasi successive del ciclo di vita. Se un errore viene rilevato tempestivamente, sarà più semplice creare soluzioni adeguate.

Se gli sviluppatori non vogliono eseguire il deployment del ramo main ogni volta, possono crearne uno production. Piuttosto che utilizzare uno script o eseguire l'operazione manualmente, i team possono sfruttare l'automazione oppure fare in modo che un ramo specifico attivi un deployment di produzione.

Gli sviluppatori devono utilizzare tags in modo che la CI esegua un'azione anziché fare in modo che la CI apporti modifiche al repository. Se i team necessitano di metriche approfondite, devono disporre di un report sul server che descriva nel dettaglio le nuove versioni.

Ogni tag deve creare una nuova release. Questa pratica permette di approntare un ambiente di sviluppo ordinato ed efficiente.

Quando eseguono il push a un ramo pubblico, gli sviluppatori non devono sottoporlo a rebase, perché ciò renderebbe difficile identificare i miglioramenti e i risultati dei test durante il cherry pick. Questo suggerimento può essere ignorato nel caso in cui si chieda a qualcuno di eseguire lo squash e il rebase al termine del processo di revisione del codice per semplificare le operazioni di ripristino. Tuttavia, di norma, il codice deve essere ordinato e la cronologia realistica.

Questo suggerimento serve a evitare la creazione di rami eccessivamente lunghi. Gli sviluppatori eseguono il checkout del ramo main, realizzano una funzionalità, creano una richiesta di merge e utilizzano il ramo main come destinazione effettuando una revisione completa prima di eseguire il merge ed eliminare eventuali fasi intermedie.

Una volta identificato, un bug potrebbe venire risolto nella versione appena rilasciata ma non nel ramo main. Ciò può causare dei problemi. Per evitare una situazione di questo tipo, gli sviluppatori devono sempre eseguire il push della modifica nel ramo main e poi effettuare il cherry pick in un altro ramo patch-release.

Gli sviluppatori devono sempre illustrare e motivare il proprio operato. Un approccio persino più efficace consiste nello spiegare perché una determinata opzione sia stata preferita ad altre, così da aiutare i futuri collaboratori a comprendere il processo di sviluppo. La scrittura di messaggi di commit descrittivi è utile per le revisioni del codice e per le fasi successive del processo di sviluppo.