Framework CALMS

Le sfide e persino le emergenze sono test efficaci della cultura DevOps. Gli sviluppatori, il team operativo e i Customer Advocate affrontano il problema e lo risolvono come un team? L'analisi retrospettiva degli imprevisti si basa sul miglioramento dei risultati per il prossimo imprevisto invece che sull'individuazione delle colpe? Se la risposta è "Sì", è un segnale positivo che indica che l'organizzazione sta adottando una cultura DevOps.

Le aziende di maggior successo adottano la cultura DevOps in ogni reparto e a tutti i livelli dell'organigramma. Su una scala così ampia, il termine "DevOps" è spesso troppo limitato e non più necessario. Queste aziende dispongono di canali di comunicazione aperti e comunicano regolarmente. Ritengono che la soddisfazione dei clienti sia una responsabilità tanto del reparto di gestione del prodotto quanto del team di sviluppo. Sono consapevoli del fatto che le attività di DevOps non rappresentano il lavoro di un singolo team, ma di tutti.

L'automazione elimina il lavoro manuale ripetitivo, produce processi ripetibili e crea sistemi affidabili.

Creazione, test, distribuzione e automazione del provisioning sono punti di partenza tipici per i team, se tali operazioni non sono già state attuate. Quale migliore ragione per sviluppatori, tester e operatori di lavorare insieme se non quella di creare sistemi a vantaggio di tutti?

I team appena entrati nel mondo dell'automazione in genere iniziano con la continuous delivery: una procedura che prevede l'esecuzione di tutte le modifiche del codice attraverso una serie di test automatizzati, spesso facilitati da un'infrastruttura basata su cloud, per poi creare un pacchetto di build e promuoverne l'uso negli ambienti mediante distribuzioni automatizzate.

Questo perché, rispetto alle persone, i computer eseguono i test in modo più rigoroso e accurato e questi test sono in grado di rilevare bug e difetti di sicurezza con una maggiore tempestività. Inoltre, durante la distribuzione automatica, il reparto IT/operativo viene avvisato in caso di discrepanze tra gli ambienti, il che consente di ridurre spiacevoli sorprese al momento del rilascio.

Un altro importante contributo di DevOps è la "Configuration as Code". Gli sviluppatori cercano di creare applicazioni modulari e componibili perché sono più affidabili e di più facile manutenzione. Lo stesso ragionamento può essere esteso all'infrastruttura che le ospita, indipendentemente da dove questa risieda, nel cloud o sulla rete aziendale.

"Configuration as Code" e "continuous delivery" non sono gli unici tipi di automazione presenti nel mondo DevOps, ma meritano una menzione speciale perché aiutano ad abbattere i muri tra i team di sviluppo e operativi. Inoltre, quando il team DevOps utilizza distribuzioni automatiche per inviare codice accuratamente testato ad ambienti con provisioning identico, la frase "sul mio computer funziona" diventa irrilevante.

Quando sentiamo parlare di "Lean" nell'ambito del software, in genere pensiamo all'eliminazione di attività a basso valore aggiunto e a movimenti rapidi, scattanti, Agile. Ancora più rilevanti per DevOps sono i concetti di miglioramento continuo e accettazione degli errori, che sono alla base di un approccio sperimentale.

La mentalità DevOps riconosce opportunità di miglioramento continuo ovunque. Alcune sono ovvie, ad esempio l'organizzazione di retrospettive condotte regolarmente per migliorare i processi del team. Altre sono più sottili, ad esempio test A/B che sperimentano diversi approcci di onboarding per nuovi utenti del prodotto.

Il miglioramento continuo è diventata un'idea di tendenza grazie allo sviluppo Agile. I primi ad adottare la metodologia Agile hanno dimostrato che un prodotto semplice nelle mani dei clienti oggi è più prezioso di un prodotto perfetto nelle mani dei clienti tra sei mesi. Se il prodotto viene migliorato continuamente, i clienti resteranno fedeli.

Tuttavia, gli errori sono inevitabili. Quindi, tanto vale preparare il team a rilevarli, correggerli e imparare da essi (alcuni definiscono questo approccio come “anti-fragile”). In Atlassian, riteniamo che se non sbagli almeno una volta ogni tanto, significa che non ti stai impegnando abbastanza.

Nel contesto di DevOps, l'errore non è un reato punibile. I team partono dal presupposto che prima o poi qualcosa è destinato ad andare storto, pertanto si preparano a rapidi rilevamenti e ripristini. Le analisi retrospettive si focalizzano su dove si sono verificati gli errori nei processi e su come rafforzare i processi stessi, non su quale membro del team abbia commesso errori nella creazione di codice. Questo perché il miglioramento continuo e gli errori vanno di pari passo.

Senza dati è difficile dimostrare che i tentativi di miglioramento continuo stiano effettivamente producendo dei risultati. Fortunatamente, sono disponibili moltissimi strumenti e tecnologie per misurare le prestazioni, come il tempo di utilizzo del prodotto da parte degli utenti, le vendite generate da post del blog o la frequenza con cui vengono visualizzati avvisi critici nei log.

Sebbene sia possibile misurare praticamente tutto, ciò non significa che si debba misurare tutto. Prendi ispirazione dallo sviluppo Agile e inizia dalle basi:

Quanto tempo ci è voluto per passare dallo sviluppo alla distribuzione?

Con che frequenza si verificano bug o errori ricorrenti?

Quanto tempo occorre per il ripristino dopo un errore di sistema?

Quante persone utilizzano il prodotto attualmente?

Quanti utenti hai acquisito/perso questa settimana?

Con una base solida, è più facile acquisire metriche sofisticate sull'utilizzo delle funzioni, sui percorsi dei clienti e sugli accordi sui livelli di servizio (SLA). Le informazioni ottenute sono utili al momento della definizione degli obiettivi e delle specifiche per la prossima grande mossa.

Tutti questi dati utili aiuteranno il tuo team a prendere decisioni, ma saranno ancora più preziosi se condivisi con altri team, soprattutto di altri reparti. Ad esempio, il team di marketing è sempre alla ricerca di nuove funzioni da commercializzare. Tuttavia, nel frattempo si assiste a un tasso elevato di abbandono da parte dei clienti perché il prodotto è sommerso dal debito tecnico. Fornire dati utente a supporto della tua roadmap, anche se carenti di funzioni e pieni di correzioni, consente di creare consenso più facilmente e di ottenere la fiducia degli stakeholder.

Per quanto auspicata, la bacchetta magica che trasforma tutti i team in team DevOps ad alte prestazioni non esiste e le trasformazioni DevOps richiedono una combinazione di pratiche, filosofie culturali e strumenti. Tuttavia, è uno sforzo che vale la pena compiere, visti i vantaggi che derivano dall'abbattimento dei silos dei team di sviluppo e operativi: maggiore fiducia, rilasci software più rapidi, distribuzioni più affidabili e un ciclo di feedback migliore tra team e clienti.

L'adozione di DevOps non è un'attività semplice. Tuttavia, con la mentalità, l'impegno e gli strumenti giusti, un'organizzazione può operare al suo interno una trasformazione DevOps che offre vantaggi significativi.

L'attrito di lunga data tra team di sviluppo e operativi è dovuto in gran parte alla mancanza di un terreno comune. Riteniamo che la condivisione di responsabilità e successi possa fare molto per colmare questo divario. Gli sviluppatori possono ottenere gratitudine immediata contribuendo a farsi carico di uno dei principali oneri dei team operativi: il pager (che al giorno d'oggi è più un concetto simbolico). La cultura DevOps è fermamente convinta che le stesse persone che creano un'applicazione debbano essere coinvolte nel rilascio e nella gestione.

Da questa idea nasce il concetto che chi crea qualcosa la gestisce, il che favorisce un approccio pratico tra team. Ciò non significa assumere sviluppatori e aspettarsi semplicemente che siano anche eccellenti. Significa che sviluppatori e operatori devono collaborare in tutte le fasi del ciclo di vita dell'applicazione. Inoltre, i report hanno dimostrato che il codice e i prodotti sottoposti a revisione paritaria rappresentano l'unica revisione che si traduce in un miglioramento della consegna e delle prestazioni; di fatto, l'efficacia della revisione esterna non si è rivelata maggiore rispetto alla scelta di non condurre alcuna revisione.

I ruoli all'interno dei team che adottano DevOps sono spesso intercambiabili. Ad esempio, gli sviluppatori che gestiscono i ticket rilevati dagli utenti finali risolvono anche i problemi di produzione. Queste persone rispondono ai ticket urgenti segnalati dai clienti, creando patch quando necessario, e agiscono tramite il backlog dei difetti segnalati dai clienti. Lo "sviluppatore di assistenza" apprende molto sul modo in cui l'applicazione viene utilizzata nella vita reale. Inoltre, grazie all'elevata disponibilità del team operativo, i team di sviluppo costruiscono fiducia e rispetto reciproco.

Atlassian ha creato Open DevOps per i team che vogliono creare la toolchain desiderata con gli strumenti che preferiscono grazie alle integrazioni con i fornitori leader di settore e alle app del Marketplace. Provalo subito.