Branching e distribuzione continua

In Capitolo 4: Tracciare ciò che conta - KPI e dashboardabbiamo analizzato come la visualizzazione del flusso di lavoro e la definizione dei giusti KPI us aiutato a individuare i colli di bottiglia e ad allineare i nostri team sulla fornitura di valore. Con una migliore visibilità della nostra pipeline DevOps, abbiamo iniziato a porci domande più profonde: non solo dove erano i colli di bottiglia, ma anche perché si verificavano.

Nel Capitolo 5, ci immergiamo in uno dei cambiamenti più significativi a livello tecnico e di processo nel nostro percorso di trasformazione: l'affinamento della nostra strategia di ramificazione e l'abilitazione del deployment continuo. Questi cambiamenti sono stati fondamentali per risolvere i persistenti ritardi tra sviluppo e produzione.

Identificare il nuovo collo di bottiglia

L'analisi del flusso di lavoro e l'identificazione dei colli di bottiglia in cui il lavoro si accumula è stato un aspetto fondamentale per realizzare la nostra trasformazione DevOps. Questa attenzione al flusso è alla base del modo in cui abbiamo applicato il triangolo DevOps - strumenti, architettura e persone - per ottenere consegne più rapide e affidabili.

Mentre facevamo progressi nel migliorare la testabilità con l'aumento della copertura dei test unitari e dell'automazione dei test, abbiamo scoperto che la qualità del codice stava migliorando, ma il collo di bottiglia era ancora nella fase di scrum testing. Nonostante i progressi nell'automazione dei test, il lavoro si accumulava ancora e il collo di bottiglia si spostava dallo sviluppo ai test a livello di sistema. Gli indicatori chiave di prestazione (KPI) mostravano che il lavoro in corso per team durante lo sviluppo stava diminuendo, ma il codice continuava a bloccarsi nel punto di transizione verso il collaudo del sistema. Questo ritardo, in ultima analisi, us impedito di ottenere un flusso regolare.

La causa principale: Strategia di ramificazione e fusioni ritardate

L'analisi ha rivelato che la causa principale del backlog risiedeva nella nostra strategia di ramificazione. Gli sviluppatori e i tester creavano rami di funzionalità dal ramo principale quando avviavano nuove funzionalità. Man mano che il codice si sviluppava, gli ingegneri spingevano le loro modifiche nei rami remoti per unire il loro lavoro a quello degli altri. Tuttavia, questo codice non veniva reinserito nel ramo principale con sufficiente frequenza.

Le pipeline CI/CD erano impostate sul ramo principale, con l'esecuzione di test automatizzati e il deploy sul cloud, seguiti da test di regressione. Tuttavia, dal momento che le ultime modifiche non venivano trasferite regolarmente al ramo principale, le esecuzioni delle pipeline venivano eseguite su codice obsoleto, rendendole ridondanti e inefficaci.

La soluzione: rami di funzioni di breve durata

Per risolvere questo problema, ci siamo resi conto che era necessario perfezionare la strategia di ramificazione. Sebbene ci siano pro e contro per le diverse strategie di ramificazione, abbiamo deciso di continuare con la strategia dei rami di funzionalità, ma con un aggiustamento chiave: rami di funzionalità di breve durata che vengono uniti al ramo principale con maggiore frequenza.

La strategia dei rami di breve durata offre diversi vantaggi, il più importante dei quali è il miglioramento del flusso e la risoluzione dei colli di bottiglia nel ciclo di sviluppo. I rami di breve durata assicurano che le fusioni del codice siano più facili, più veloci e meno soggette a errori. Questo approccio consente anche un feedback più rapido, che migliora la qualità complessiva e la velocità del processo di sviluppo.

Distribuzione continua: La sfida della pipeline

La creazione di solide pipeline di distribuzione continua è un compito complesso che richiede un approccio mirato e incrementale. Secondo la nostra esperienza, l'approccio consigliato è quello di avere un team dedicato alla piattaforma che si occupi dell'impostazione e della manutenzione di queste pipeline, piuttosto che far lavorare ogni team di scrum su di esse individualmente. Anche se la proprietà finale delle pipeline di consegna continua deve spettare ai team di scrum, il compito iniziale di configurarle trae grande beneficio da un team di piattaforma dedicato.

Team della piattaforma: Ridurre il carico cognitivo e favorire la concentrazione

Per trovare ispirazione nella strutturazione del nostro team di piattaforma, ci siamo rivolti a Team Topologies di Matthew Skelton e Manuel Pais. Il libro sottolinea l'importanza di avere un team dedicato alla piattaforma, responsabile della creazione e della gestione dell'infrastruttura -nel nostro caso, delle pipeline CD. Questa struttura consente ai team Scrum di concentrarsi sullo sviluppo delle funzionalità, beneficiando al contempo di una configurazione stabile e standardizzata delle pipeline.

Come si legge nel libro:

"Il team della piattaforma è responsabile della costruzione e della manutenzione della piattaforma interna che i team allineati ai flussi utilizzano per svolgere il loro lavoro. Lo scopo della piattaforma è ridurre il carico cognitivo dei team allineati ai flussi, in modo che possano concentrarsi sulla creazione di valore."

Centralizzando la responsabilità delle pipeline, siamo stati in grado di creare una piattaforma comune e condivisa da cui i team allineati ai flussi potessero dipendere. Questo us ha permesso di ridurre il carico cognitivo dei team di sviluppo, consentendo loro di concentrarsi sull'offerta di valore piuttosto che sulle questioni infrastrutturali.

Evoluzione della piattaforma per il miglioramento continuo

Avere un team di piattaforma non significa solo impostare le pipeline, ma anche far evolvere l'infrastruttura e gli strumenti condivisi nel tempo. Un team dedicato alla piattaforma è nella posizione migliore per apportare miglioramenti incrementali alla pipeline di consegna continua, assicurando che rimanga allineata con le esigenze dei team e che si adatti alla nostra scalabilità e crescita. Questa evoluzione continua garantisce che la piattaforma rimanga affidabile, scalabile ed efficiente, consentendo ainostri team di lavorare al meglio.

Prossimamente: Automazione e feedback

Con la ramificazione semplificata e le distribuzioni fluide, passiamo all'ultima frontiera del nostro viaggio DevOps: Automazione e feedback. Nel prossimo e ultimo capitolo, esploreremo come la chiusura del ciclo con intuizioni automatizzate e feedback rapidi abbia trasformato il modo di operare dei nostri team.

Restate sintonizzati!