3 min di lettura
Nel Capitolo 4: Monitorare ciò che conta – KPI e dashboard, abbiamo analizzato come la visualizzazione del flusso di lavoro e la definizione dei giusti KPI ci abbiano aiutato a individuare i colli di bottiglia e ad allineare i nostri team sulla creazione di valore. Con una maggiore visibilità sulla nostra pipeline DevOps, abbiamo iniziato a porre domande più approfondite, non solo per capire dove fossero i colli di bottiglia, ma anche perché si verificassero.
Nel Capitolo 5, approfondiamo uno dei cambiamenti tecnici e di processo più significativi nel nostro percorso di trasformazione: il perfezionamento della nostra strategia di branching e l'abilitazione del continuous deployment. Questi cambiamenti sono stati fondamentali per risolvere i ritardi persistenti tra lo sviluppo e la produzione.
Identificare il nuovo collo di bottiglia
Analizzare il flusso di lavoro e identificare i colli di bottiglia in cui il lavoro si accumula è stato un aspetto chiave per realizzare la nostra trasformazione DevOps. Questa attenzione al flusso è al centro del modo in cui abbiamo applicato il triangolo DevOps—strumenti, architettura e persone—per ottenere una consegna più rapida e affidabile.
Mentre facevamo progressi nel migliorare la testabilità con una crescente copertura di unit test e test automation, abbiamo riscontrato che la qualità del codice stava migliorando, ma il collo di bottiglia persisteva nella fase di test dello scrum. Nonostante i progressi nell'automazione dei test, il lavoro continuava ad accumularsi e il collo di bottiglia si è spostato dallo sviluppo ai test a livello di sistema. Gli indicatori chiave di prestazione (KPI) hanno mostrato che il lavoro in corso per team durante lo sviluppo stava diminuendo, ma il codice continuava a bloccarsi nel punto di transizione verso i test di sistema. Questo ritardo ha finito per impedirci di raggiungere un flusso continuo.
La causa principale: strategia di branching e merge ritardati
L'analisi ha rivelato che la causa principale dell'arretrato risiedeva nella nostra strategia di branching. Sviluppatori e tester creavano branch di funzionalità dal branch principale quando iniziavano nuove funzioni. Con lo sviluppo del codice, i tecnici inviavano le modifiche ai branch di funzionalità remoti per unire il loro lavoro a quello degli altri. Tuttavia, questo codice non veniva riunito nel branch principale con la frequenza necessaria.
Le pipeline CI/CD erano configurate sul branch principale, eseguendo test automatizzati e distribuendo sul cloud, seguiti da test di regressione. Tuttavia, poiché le modifiche più recenti non venivano inviate regolarmente al branch principale, le esecuzioni della pipeline venivano eseguite su codice obsoleto, risultando ridondanti e inefficaci.
La soluzione: branch di funzionalità a breve durata
Per risolvere questo problema, abbiamo capito che era necessario ottimizzare la strategia di branching. Sebbene vi siano vantaggi e svantaggi in diverse strategie di branching, abbiamo deciso di continuare con la strategia dei branch di funzionalità, ma con un adeguamento fondamentale: branch di funzionalità a breve durata che vengono uniti nuovamente al branch principale con maggiore frequenza.
La strategia dei branch di funzionalità a breve durata offre diversi vantaggi, il cui beneficio più critico è il miglioramento del flusso e la risoluzione dei colli di bottiglia nel ciclo di sviluppo. Branch più brevi assicurano che le fusioni di codice siano più semplici, veloci e meno soggette a errori. Questo approccio consente inoltre un feedback più rapido, che migliora la qualità complessiva e la velocità del processo di sviluppo.
Continuous Deployment: la sfida della pipeline
Configurare pipeline di continuous deployment robuste è un compito complesso che richiede un approccio mirato e graduale. In base alla nostra esperienza, disporre di un team di piattaforma dedicato per configurare e mantenere queste pipeline è l'approccio consigliato, piuttosto che affidare il compito a ciascun team scrum individualmente. Sebbene la titolarità finale delle pipeline di continuous delivery debba spettare ai team scrum, il compito iniziale di configurarle trae enormi vantaggi dalla presenza di un team di piattaforma dedicato.
Team di piattaforma: riduzione del carico cognitivo e focus sugli obiettivi
Per trovare ispirazione nella strutturazione del nostro team di piattaforma, abbiamo fatto riferimento a Team Topologies di Matthew Skelton e Manuel Pais. Il libro sottolinea l'importanza di avere un team di piattaforma dedicato responsabile della configurazione e della gestione dell'infrastruttura—nel nostro caso, le pipeline CD. Questa struttura consente ai team scrum di concentrarsi sullo sviluppo delle funzionalità, beneficiando al contempo di una configurazione della pipeline stabile e standardizzata.
Come afferma il libro:
“Il team della piattaforma è responsabile della creazione e della manutenzione della piattaforma interna utilizzata dai team orientati al flusso per svolgere il proprio lavoro. Lo scopo della piattaforma è ridurre il carico cognitivo per questi team, consentendo loro di concentrarsi sulla creazione di valore”.
Centralizzando la responsabilità delle pipeline, siamo stati in grado di creare una piattaforma condivisa e comune su cui i team orientati al flusso potessero fare affidamento. Questo ci ha permesso di ridurre il carico cognitivo sui team di sviluppo, consentendo loro di concentrarsi sulla creazione di valore anziché occuparsi dei problemi legati all'infrastruttura.
Evoluzione della piattaforma per il miglioramento continuo
Avere un team di piattaforma non significa solo configurare le pipeline; significa far evolvere l'infrastruttura condivisa e gli strumenti nel corso del tempo. Un team di piattaforma dedicato è nella posizione ideale per apportare miglioramenti incrementali alla pipeline di distribuzione continua, assicurandosi che rimanga allineata alle esigenze dei team e si adatti alla nostra crescita. Questa continua evoluzione garantisce che la piattaforma rimanga affidabile, scalabile ed efficiente, consentendo ai nostri team di dare il meglio.
Prossimamente: Automazione e feedback
Con la gestione dei rami semplificata e i rilasci fluidi, passiamo all'ultima frontiera del nostro percorso DevOps: Automazione e feedback. Nel prossimo e ultimo capitolo, analizzeremo come la chiusura del cerchio tramite approfondimenti automatizzati e un feedback rapido abbia trasformato il modo in cui operano i nostri team.
Rimanete sintonizzati!
