Le best practice DevOps da adottare subito in azienda

Il successo della strategia IT di un'azienda passa dalla capacità di far funzionare al meglio sia i team di sviluppo sia quelli che gestiscono le operations. Le pratiche DevOps nascono per ottimizzare queste attività: si tratta di una metodologia per ottimizzare i processi di sviluppo di software moderni creata per aumentare la sinergia tra il team Dev (developers) e il team Ops (operations), di solito separati e abituati a lavorare senza quasi comunicare.

È un cambiamento culturale, oltre che operativo, che permette di migliorare radicalmente il time-to-market dell’applicazione, far crescere la produttività e ridurre i costi operativi. Oggi sono requisiti non più opzionali per essere competitivi sul mercato.

LEGGI ANCHE: Cos'è DevOps e come adottarlo

Affinché la collaborazione tra i due team sia efficace è necessario seguire una serie di regole e di best practices: vediamo allora 6 buone prassi per adottare DevOps in azienda con successo.

Best practice 1: test automatizzati

Fare test è imprescindibile in tutto il ciclo di vita di sviluppo software per rilasciare codice e prodotti di qualità; nelle pratiche agili fare TDD (Test Drive Development) è uno dei pilastri.

DevOps favorisce un’attività di testing automatizzato già in fase iniziale, così da permettere agli sviluppatori di identificare e risolvere eventuali problemi durante lo sviluppo anziché in uno stadio più avanzato del ciclo di vita del software.

Quali sono i benefici dei test automatizzati?

• Test più frequenti: rispetto al testing manuale, quello automatizzato permette di eseguire più test senza impegnare risorse del team
• Test più affidabili: cala notevolmente il rischio di errori umani
• Test più complessi: automatizzando la fase di testing è possibile effettuare test con complessità che difficilmente potrebbero essere gestite dagli operatori
• Migliore utilizzo delle risorse umane: i membri del team possono dedicarsi ad attività non automatizzabili e dal maggior valore aggiunto

Best practice 2: CI/CD e automazione

Le pratiche della Continuous Integration e Continuous Delivery (CI/CD) riguardano proprio l’automazione dei processi di QA. Questa pratica permette al team di integrare e distribuire il proprio codice “continuamente”, ovvero con estrema frequenza, senza attendere che operatori a valle terminino onerose fasi di controllo e senza delega di responsabilità. I test automatizzati possono includere test end-to-end, unitari, di integrazione, test di sicurezza e delle prestazioni e persino test di consistenza visuale.

In generale, l’automazione è essenziale per DevOps: ogni processo ripetibile può essere automatizzato, lasciando agli sviluppatori energie e tempo per creare valore di business.

LEGGI ANCHE: CI/CD best practice

Best practice 3: Anticipare i problemi

Un team che tiene alla qualità cerca di anticipare il più possibile l’identificazione dei difetti: prima si conosce un problema e prima lo si può indirizzare.

Invece di produrre codice in gran quantità e velocemente, delegando a un team di QA separato la responsabilità di scoprire i difetti (per poi vedersi tornare indietro codice da sistemare, rendendo perfettamente inutile ogni pianificazione), gli sviluppatori scrivono procedure per testare in autonomia il codice che creano.

Le procedure possono essere quindi automatizzate e l’automazione riduce notevolmente i costi dei test.

Best practice 4: Monitoraggio

Un team DevOps concentrato sulla produzione di valore delega il monitoraggio dei risultati degli automatismi a strumenti software.

Compito di questi strumenti di integrazione è quello di notificare immediatamente in caso di una build non funzionante o un test non riuscito, così che gli sviluppatori possano risolvere quei problemi, evitando di ritardare la consegna o (peggio) consegnare software con difetti.

L'automazione migliora enormemente la velocità di sviluppo, ma se si verifica un errore in un processo automatizzato e nessuno lo sa, tanto vale fare il lavoro manualmente. Allo stesso modo, è importante monitorare le applicazioni di produzione al fine di identificare guasti o carenze di prestazioni, prima che ad accorgersene siano gli utenti finali.

Best practice 5: Osservabilità

Con il passaggio da applicazioni e sistemi monolitici on-premise ad applicazioni Cloud Native e basate su microservizi, il monitoraggio diventa notevolmente più complesso.

Se un problema avviene in una rete di microservizi, come possiamo rintracciarlo? Come possiamo risalire la catena causa-effetto velocemente e con confidenza? Ecco perché oggi si parla tanto di osservabilità. Si dice che i tre pilastri dell'osservabilità siano log, tracing e metriche.

• I log vengono generati dalla maggior parte dei componenti e delle applicazioni di sistema e sono costituiti da registri cronologici sul funzionamento del sistema o dell'applicazione.
• Il tracing tiene traccia della logica all'interno dell'applicazione, permettendo di ripercorrerlo a ritroso in caso di problemi.
• Le metriche rappresentano su scala temporale l’utilizzo delle risorse come CPU, RAM, spazio su disco, connettività di rete ma anche i tempi di risposta, la velocità di esecuzione, etc.

Osservabilità significa semplicemente utilizzare tutte e tre queste fonti di informazione in modo aggregato per analizzare e prevedere il funzionamento di un sistema complesso, altrimenti impossibile da gestire con sicurezza.

Best practice 6: Raccogli feedback continuo

Un flusso continuo di feedback garantisce che i membri del team dispongano di tutte le informazioni necessarie per svolgere il proprio lavoro in modo tempestivo e rilevante.

Dal punto di vista dello sviluppo, ciò implica che il team venga immediatamente notificato in caso di problemi in fase di integrazione o delivery. Significa anche che i risultati dei test, chiari e approfonditi, devono essere resi disponibili agli sviluppatori il più rapidamente possibile.

Dal punto di vista della gestione del prodotto, il team viene informato di eventuali errori di produzione, carenze di prestazioni o bug segnalati tramite canali che permettono di tenere traccia di queste informazioni in modo che non si perdano nel caos.

In generale si pensa di dover scegliere tra qualità e velocità. Aprirsi a un feedback costante e trasparente è uno degli elementi di DevOps che rende possibile, nel tempo, ottenere entrambi i risultati.

Conclusione

Le pratiche DevOps sono incrementali: non è necessario un cambiamento radicale in un giorno. Meglio implementarle un po' alla volta.

I cambiamenti di cultura nelle aziende richiedono sostanzialmente tre cose: un piano cronologicamente ben strutturato, il giusto approccio comunicativo per spiegarlo e il tempo necessario per attuarlo, cioè per consentire alle persone di accettare il cambiamento in modo naturale. In quest'ottica, le best practice DevOps rappresentano una guida che indica quali sono gli obiettivi operativi da raggiungere.