Skip to main content

DevOps si è affermato come una filosofia essenziale, colmando il divario tra lo sviluppo software e le operazioni IT. Va oltre il semplice utilizzo di strumenti DevOps. Un team DevOps di successo non solo accelera il processo di delivery ma garantisce qualità e affidabilità. Tuttavia, creare un tale team richiede una fusione armoniosa di strumenti, cultura, processi, collaborazione e altro ancora. Quali sono i componenti critici di un team DevOps di alto livello, e come possono le organizzazioni integrarli per ottenere risultati ottimali? Come parte di questa serie, abbiamo avuto il piacere di intervistare Dylan Etkin, co-fondatore e CEO di Sleuth.

Ciao Dylan – Puoi raccontarci la tua storia?

Ho iniziato la mia carriera come ingegnere software. Sono stato fortunato ad entrare in una piccola startup, Atlassian, come loro ventesimo dipendente. Ho trascorso 10 anni in Atlassian imparando tantissimo e osservando la crescita dell'organizzazione da 20 a 1200 persone. Ho lavorato come uno dei primi 3 ingegneri su Jira, sono stato il primo Jira Architect e Lead dell'Engineering per Bitbucket, facendo crescere quel prodotto da 40K a 2M utenti. 

Vuoi di più da The CTO Club?

Crea un account gratuito per completare questo articolo e unirti a una comunità di CTO e leader ingegneristici che condividono framework, strumenti e approfondimenti reali per progettare, implementare e scalare tecnologie guidate dall'IA.

This field is for validation purposes and should be left unchanged.
Name*

Ho lasciato Atlassian e mi sono unito ad una piccola startup, Statuspage. Un anno dopo, Statuspage è stata acquisita da Atlassian, e mi sono ritrovato di nuovo nella "casa madre". Dopo 3 anni alla guida di quel team in Atlassian, ho deciso di mettermi in proprio, fondando Sleuth per trasformare in prodotto quella che è sempre stata la mia passione: costruire team di ingegneria efficienti.

Sono sempre stato affascinato dagli strumenti per sviluppatori e dall'aiutare i team ad essere efficienti e ad apprendere continuamente.

A chi attribuisci il merito di averti aiutato a raggiungere il successo?

Molte persone mi hanno aiutato lungo il viaggio. Più invecchio, più mi rendo conto di quanto sia speciale la rete che ho costruito e di quanto siano tutti disponibili ad aiutare quando si chiede.

Un esempio che mi viene in mente è John Kodumal, co-fondatore e CTO di LaunchDarkly. John ed io eravamo colleghi ai tempi di Atlassian. Quando decise di fondare LaunchDarkly, fu sempre disponibile a condividere apertamente la sua esperienza di startup.

Quando ho iniziato a motivarmi per avviare Sleuth, mi ha supportato su tutti i livelli. Dalla discussione delle idee a conversazioni aperte su come procedere, fino ad iscriversi come nostro primo cliente, John mi ha aiutato in ogni fase del mio percorso. 

Puoi condividere con noi tre punti di forza, competenze o caratteristiche che ti hanno aiutato ad arrivare dove sei oggi? Come possono altri sviluppare attivamente queste aree in sé stessi? 

  1. Perseveranza. La competenza e l’intelligenza ti portano solo fino a un certo punto. Tornare su un problema più e più volte è molto più potente. La perseveranza, anche di fronte a fallimenti multipli, è ciò che ha definito il mio successo.
  2. Attenzione ai dettagli. Questa è una caratteristica che mi è sempre venuta naturale. Da ingegnere, è una competenza fondamentale che ti permette di portare a termine le attività in modo eccellente. In una startup, questa competenza è ancora più importante. Guidare un prodotto dall’idea alla realtà, l’attenzione ai dettagli fa la differenza tra un prodotto mediocre e qualcosa che gli utenti amano.
  3. Delegare. Per quanto sia necessario sentirsi pienamente responsabili del proprio business, una startup molto rapidamente si trasforma in un esercizio di assunzione di persone più competenti di te in tante aree e nell’abbracciare il "passare i tuoi lego" perché altri abbiano successo e spingano il tuo business avanti. 

Quali abilità stai ancora cercando di sviluppare?

Sto sempre lavorando su molte cose; non manca mai qualche abilità da migliorare. Al momento, il mio focus è l’arte di ottenere il meglio dalle persone. Tutti sono diversi e sapere come creare un ambiente in cui ciascuno possa dare il meglio di sé è una sfida.

Parliamo di come avere un team DevOps di successo. Quali sono gli obiettivi chiave che un team DevOps potrebbe individuare per un percorso di trasformazione digitale?

I team DevOps hanno il potere di portare efficacemente il lavoro dall’ideazione al lancio in produzione. Pertanto, l’obiettivo numero uno per un team DevOps è costruire strumenti, processi e cultura che permettano agli sviluppatori di portare rapidamente il lavoro dall’idea all’avvio efficace in produzione. 

Obiettivi che supportano il raggiungimento del primo obiettivo sono:

  • Capacità di definire il lavoro in piccoli lotti
  • Una pipeline CI/CD completamente automatizzata
  • Osservabilità e ambienti pre-produzione che funzionano come reti di sicurezza affinché gli sviluppatori possano inviare modifiche in produzione con fiducia
  • Un processo chiaro su cosa fare quando qualcosa va storto. Tutti sanno come rilevare i problemi e ripristinare il sistema ad uno stato funzionante
  • Coinvolgimento del resto dell’organizzazione: PM, Marketing, Supporto, Vendite ed Executive. I team non riusciranno a realizzare una trasformazione DevOps senza il supporto dell’intera organizzazione

Ci sono ostacoli o errori comuni che i team DevOps dovrebbero tenere in considerazione?

Ce ne sono troppi per elencarli tutti. Uno che spicca è rendersi conto che praticare DevOps significa attribuire maggiore responsabilità allo sviluppatore. Questo non avviene senza costi e, se non si investe in processi e strumenti, si rischia di costruire un sistema che non lascia tempo agli sviluppatori per fare effettivamente il loro lavoro.

Corri anche il rischio di creare un ambiente in cui gli sviluppatori vanno incontro a rapido burnout. Devi ricordare che le persone hanno una capacità limitata, quindi devi prestare attenzione a ciò che implementi per supportare gli sviluppatori che praticano DevOps.

In che modo una collaborazione e comunicazione efficace tra i membri del team può aumentare la produttività e il successo di un team DevOps, e quali pratiche possono favorirlo?

Comunicazione e collaborazione sono fondamentali per praticare DevOps. Alcune pratiche importanti includono:

  • Utilizzare un issue tracker per tutto il lavoro e includere quel contesto e tali informazioni nei commit e nelle revisioni del codice
  • Code review tramite pull request
  • Fornire una soluzione di chat in tempo reale come Slack per il tuo team
  • Notifiche di deployment per il team tramite Slack o tramite il tuo strumento ChatOps di squadra
  • Approvazioni tramite Slack per la promozione delle modifiche dagli ambienti di pre-produzione a produzione
  • Notifiche individuali agli sviluppatori quando le loro modifiche vengono distribuite oppure quando vengono superati i limiti di errore
  • Visibilità del team su incidenti e periodi in cui bisogna attendere per effettuare deployment
  • Demo di team con i PM e gli altri stakeholder
  • Riunioni giornaliere (daily standup)

Che ruolo svolge CI/CD nel DevOps, e quali sono le best practice per implementare pipeline CI/CD che garantiscano un processo di rilascio software fluido e affidabile?

CI/CD è forse l’elemento di tooling più importante a supporto di un team che pratica DevOps. L’ideale è che i team abbiano una pipeline di deployment completamente automatizzata che si esegua in tempi ragionevoli, in modo che gli sviluppatori non debbano attendere a lungo e possano condurre le proprie modifiche fino alla produzione. È fondamentale includere CI ed esecuzione dei test in questa pipeline ideale. Eseguire una suite di test robusta sulle modifiche come filtro prima del deployment rappresenta la principale rete di sicurezza per garantire che vengano rilasciate solo buone modifiche. 

Se i team desiderano rilasciare solo una volta a settimana, è possibile avere una pipeline di deployment non completamente automatizzata. Tuttavia, se il team vuole rilasciare almeno una volta al giorno, è necessario avere tutto automatizzato e il deployment deve diventare un non-evento.

In che modo promuovere una cultura DevOps e una mentalità DevOps contribuisce al successo complessivo di un team DevOps, e quali strategie possono adottare le organizzazioni per favorire questa cultura tra team di sviluppo e operation?

Per sviluppatori:

  • Una pianificazione degli sprint settimanale o bisettimanale può aiutare a definire la dimensione delle attività e creare un accordo di squadra su come inserirle nella finestra di tempo
  • CI automatizzata sul branch di rilascio e visibilità dei risultati a tutto il team, per aiutare la squadra a mantenere il branch di rilascio funzionante
  • Mantenere un ruolo di “disturbato” nel team in cui sia chiaro di chi è la responsabilità di mantenere il branch di rilascio funzionante
  • Uno dei migliori meccanismi per essere in grado di rilasciare lavoro incompleto è adottare una qualche forma di flag di funzionalità (feature flagging).
  • Può essere anche molto efficace distribuire ogni pull request individualmente. Adottando questo modello, puoi includere la revisione della dimensione dei batch di una modifica nella revisione della pull request stessa. Se un batch è troppo grande, gli altri membri del team possono chiedere di suddividerlo in più pull request.
  • Disporre di abbastanza metriche e conoscerne le soglie standard per poter verificare un deploy
  • Saper gestire le escalation e sapere come effettuare rollback, se necessario
  • Essere autorizzati a distribuire i propri cambiamenti in tutti gli ambienti mantenuti e poterlo fare rapidamente e senza errori

Per PM e designer:

  • Coinvolgere il PM nella fase di pianificazione per permettergli di esprimere le esigenze del cliente nei rilasci incrementali.
  • Implementare i feature flag, consentendo al codice di essere distribuito ma non ancora visibile agli utenti. Questo aiuta i PM a mantenere la flessibilità di cui hanno bisogno, lasciando ai developer la possibilità di proseguire velocemente.
  • Avere un meccanismo concordato per feedback e rework, come ad esempio un ticket assegnato direttamente a uno sviluppatore. Una strategia per risolvere il problema del lavoro incompleto può essere adottare cicli di sei settimane per il team.

Per Engineering Manager:

  • Implementare processi che facilitino la comunicazione, come pianificazioni ricorrenti, code review e demo settimanali.
  • Impegnarsi a dedicare tempo ingegneristico per mantenere passanti le build del branch di rilascio. Garantire il flusso del codice vuol dire anche investire su questo nuovo sistema. Quando il team identifica un collo di bottiglia, il manager dovrebbe essere in grado di consentire alla squadra di rimuoverlo (ad esempio, correggere i test CI con una fluttuazione superiore al 20%).
  • Implementare strumenti per misurare continuamente le metriche DORA

Per Execs:

  • Rendi visibili le metriche Accelerate per i tuoi progetti e mettile a disposizione, con contesto, ai tuoi dirigenti.
  • Rendi disponibili le statistiche sulla disponibilità o equivalenti per le tue applicazioni.
  • Fornisci al tuo team dirigente le stesse informazioni di alto livello sui grandi blocchi di funzionalità che vengono rilasciati.
  • Se sei un dirigente, comprendi che il cambiamento richiede tempo. Sii fermo nel pretendere che i tuoi team rispondano agli obiettivi di alto livello ma flessibile su come li raggiungono. Fidati, ma verifica.
  • Prenditi il tempo per spiegare alla tua organizzazione come stai portando valore ai tuoi clienti. Spiega come funziona la consegna incrementale, quali cose verranno rilasciate "tutte insieme" e come questo modo di lavorare ti possa permettere di consegnare valore ai clienti più rapidamente.

Quali sono gli elementi essenziali di un team DevOps di successo?

1. Il team lavora insieme in una cultura priva di colpe. 

Lo sviluppo software è uno sport di squadra. Incidenti ed errori sono opportunità per il team di imparare, non momenti per attribuire colpe. Una cultura priva di colpe può estendersi oltre gli incidenti. Quando si stabiliscono obiettivi di miglioramento di team, il gruppo può concentrarsi sul miglioramento dei risultati invece di accusare persone o processi del fatto che le cose non sono dove dovrebbero essere.

2. I deployment non sono un evento.

Per poter rilasciare in piccoli incrementi e rispondere velocemente a incidenti e riscontri dei clienti, il deployment deve essere facile e non generare né paura né ansia. Se un team non si fida dei propri deployment, oppure se sono troppo lenti o comportano passaggi manuali, ciò porterà a timore ed esitazione e non permetterà al team di adottare DevOps.

3. Gli sviluppatori sono individualmente abilitati a portare i cambiamenti dall’idea fino a un rilascio affidabile in produzione. DevOps funziona quando si sposta la responsabilità dell’intero processo, dall'idea al rilascio, nelle mani degli sviluppatori. Questo permette al team di suddividere il lavoro in piccoli batch e fornire rapidamente valore al cliente con piccoli incrementi.

4. Il team dispone di reti di sicurezza, come strumenti di osservabilità e misure di gestione dei guasti, così da avere la sicurezza per muoversi rapidamente (questo è uno dei tanti vantaggi degli strumenti di osservabilità dei dati). I giorni del "muoversi veloce e rompere le cose" sono finiti. Ora bisogna muoversi velocemente, ma con affidabilità. Per riuscirci, è necessario predisporre reti di sicurezza automatizzate.

5. Tutta l’organizzazione ha adottato il flusso di lavoro DevOps.

Quali tendenze emergenti prevedi nel panorama DevOps che potrebbero influenzare in modo significativo le strategie di trasformazione digitale nel futuro?

Forse questa adesso sembra una risposta ovvia, ma gli strumenti di intelligenza artificiale stanno già trasformando il modo in cui lavorano gli sviluppatori e influenzeranno certamente il modo in cui il DevOps verrà praticato in futuro. L’intelligenza artificiale sarà almeno usata per rilevare e identificare i malfunzionamenti in modi che oggi non sono possibili.

Se manterrà tutte le sue promesse, allora sostituirà completamente i complessi pipeline di deploy e test che abbiamo oggi.

Iscriviti alla Newsletter di The CTO Club per altri approfondimenti, riepiloghi, domande e risposte e molto altro!