,
3 min di lettura
Nel Capitolo 4: Monitorare ciò che conta – KPI e Dashboard, abbiamo esplorato come la visualizzazione del flusso di lavoro e la definizione dei KPI giusti ci abbiano aiutato a individuare i colli di bottiglia e ad allineare i nostri team sulla fornitura di valore. Con una migliore visibilità nella nostra pipeline DevOps, abbiamo iniziato a porci domande più profonde, non solo dove fossero i colli di bottiglia, ma perché stessero accadendo.
Nel Capitolo 5, approfondiamo uno dei cambiamenti più significativi a livello tecnico e di processo nel nostro percorso di trasformazione: perfezionando la nostra strategia di branching e abilitando il 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 dove il lavoro si accumula è stato un aspetto chiave per realizzare la nostra trasformazione DevOps. Questo focus sul flusso è al centro di come abbiamo applicato il triangolo DevOps – strumenti, architettura e persone – per ottenere consegne più rapide e affidabili.
Mentre abbiamo fatto progressi nel migliorare la testabilità con una crescente copertura di test unitari e automazione dei test, abbiamo scoperto che la qualità del codice stava migliorando, ma il collo di bottiglia era ancora nella fase di test scrum. Nonostante i progressi nell'automazione dei test, il lavoro continuava ad accumularsi e il collo di bottiglia si è spostato dallo sviluppo al 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 il test di sistema. Questo ritardo ci ha impedito di raggiungere un flusso regolare.
La Causa Principale: Strategia di Branching e Fusioni Ritardate
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 funzionalità. Man mano che il codice si sviluppava, gli ingegneri caricavano le loro modifiche su branch di funzionalità remote per unire il loro lavoro con quello degli altri. Tuttavia, questo codice non veniva re-integrato nel branch principale con sufficiente frequenza.
Le pipeline CI/CD sono state configurate sul ramo principale, eseguendo test automatizzati e distribuendo sul cloud, seguite da test di regressione. Tuttavia, poiché le ultime modifiche non venivano regolarmente inviate al ramo principale, le esecuzioni delle pipeline venivano eseguite su codice obsoleto, rendendole ridondanti e inefficaci.
La Soluzione: Rami di Funzionalità a Breve Durata
Per risolvere questo problema, abbiamo capito che era necessario ottimizzare la strategia di ramificazione. Sebbene ci siano vantaggi e svantaggi nelle diverse strategie di ramificazione, abbiamo deciso di continuare con la strategia di ramificazione per funzionalità, ma con un aggiustamento chiave: rami di funzionalità a breve termine che vengono uniti più frequentemente al ramo principale.
La strategia dei rami di funzionalità a breve termine offre numerosi vantaggi, con il beneficio più critico rappresentato da un flusso migliorato e dall'eliminazione dei colli di bottiglia nel ciclo di sviluppo. I rami a vita più breve garantiscono che le unioni di codice siano più facili, 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.
Deployment Continuo: La Sfida della Pipeline
L'implementazione di pipeline di distribuzione continua robuste è un compito complesso che richiede un approccio mirato e incrementale. Nella nostra esperienza, avere un team di piattaforma dedicato per configurare e mantenere queste pipeline è l'approccio raccomandato, piuttosto che far lavorare ogni team Scrum individualmente. Sebbene la proprietà finale delle pipeline di continuous delivery debba spettare ai team Scrum, il compito iniziale di configurazione beneficia notevolmente di un team di piattaforma dedicato.
Team della piattaforma: Riduzione del carico cognitivo e favorire la concentrazione
Per trarre 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 di piattaforma dedicato che è responsabile della configurazione e 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 di pipeline stabile e standardizzata.
Come afferma il libro:
“Il team della piattaforma è responsabile di costruire e mantenere la piattaforma interna che i team allineati ai flussi utilizzano per svolgere il proprio lavoro. Lo scopo della piattaforma è ridurre il carico cognitivo per i team allineati ai flussi, in modo che possano concentrarsi sulla creazione di valore.”
Centralizzando la responsabilità per le pipeline, siamo stati in grado di creare una piattaforma condivisa e comune su cui i team allineati al flusso potevano fare affidamento. Ciò ci ha permesso di ridurre il carico cognitivo sui team di sviluppo, consentendo loro di concentrarsi sulla fornitura di valore piuttosto che sulla gestione delle preoccupazioni relative all'infrastruttura.
Sviluppare la piattaforma per il miglioramento continuo
Avere un team di piattaforma non significa solo impostare le pipeline; si tratta di evolvere l'infrastruttura condivisa e gli strumenti nel tempo. Un team di piattaforma dedicato è nella posizione migliore per apportare miglioramenti incrementali alla pipeline di continuous delivery, assicurando che rimanga allineata alle esigenze dei team e si adatti man mano che ci espandiamo e cresciamo. Questa evoluzione continua assicura che la piattaforma rimanga affidabile, scalabile ed efficiente, consentendo ai nostri team di lavorare al meglio.
A seguire: Automazione e feedback
Con il branching ottimizzato e i deployment fluidi, ci rivolgiamo all'ultima frontiera del nostro percorso DevOps: Automazione e Feedback. Nel prossimo e ultimo capitolo, esploreremo come la chiusura del ciclo con insight automatizzati e feedback rapidi abbia trasformato il modo in cui i nostri team operano.
Resta sintonizzato!
