DevOps Heroes 2019: un breve resoconto

Sabato 26 ottobre l’Università degli Studi di Parma ha ospitato DevOps Heroes 2019.

L’evento riguardava il tema DevOps, che sta prendendo sempre più piede presso sviluppatori, sistemisti, Project Manager e tante altre figure del mondo IT.

Nel corso della giornata si sono avvicendati vari speaker per chiarire meglio gli aspetti di questo controverso tema, provenienti dall’Italia e dall’estero. Grazie agli sponsor, la conferenza DevOps Heroes 2019 era completamente gratuita.

Tutte le informazioni sull’evento e le slide delle sessioni potete trovarle già sul sito ufficiale.

Cosa si intende con il termine DevOps?

Riprendendo la definizione riportata sul sito della conferenza, DevOps è una cultura, un movimento, una pratica che si focalizza su collaborazione e comunicazione. Il suo obiettivo è quello di colmare il gap fra i diversi attori coinvolti nella produzione del software. Essa collega lo sviluppatore di software alle altre figure IT impegnate nel test e nel delivery della soluzione, includendo metodologie ma anche tool. Il risultato finale è un ecosistema affidabile e automatizzato per fare sviluppo, build e release.

Avendo partecipato come tutti solo a determinate sessioni, il mio resoconto non potrà essere esaustivo. Mi limiterò quindi a riportare gli elementi di DevOps Heroes 2019 che ho trovato più interessanti.

Microsoft Learn: una bella scoperta!

Essendo sia partner che sponsor, Microsoft ha “monopolizzato” un pochino parte dei contenuti della conferenza.

Nel talk di apertura Aldo Donetti, Senior Regional Program Manager di Microsoft, ha illustrato le funzionalità del sito Microsoft Learn e le sue potenzialità.

Oltre a includere percorsi di formazione specifici per Azure, la soluzione cloud di Redmond, il sito è in grado di offrire esercitazioni pratiche creando automaticamente le risorse cloud che sono necessarie. Ciò consente a chiunque di apprendere l’uso della piattaforma eseguendo comandi reali su architetture veraci create ad hoc, senza dover necessariamente acquistare prodotti e servizi.

Il sito annovera decine e decine di nuovi corsi e offre la possibilità di iscriversi con un profilo che è possibile rendere pubblico per mostrare i propri progressi. Oltre ad autocelebrarsi, esporre i traguardi raggiunti può tornare molto utile, ad esempio per proporsi come candidato per una posizione lavorativa aperta.

Ricordo di aver visitato il sito di recente, ma non avevo notato tutte le novità che sono state raccontate: ci farò presto una capatina e consiglio a tutti di farlo.

Continuous Integration: qual è il reale valore?

La Continuous Integration (abbreviata in “CI”) è forse uno dei maggiori capisaldi della filosofia DevOps. Molte delle sessioni ha riguardato questa pratica, direttamente o indirettamente, parlando di tool e/o di configurazioni legate alla CI.

Nata con extreme programming (XP), si tratta di una pratica che prevede l’integrazione continua e frequente dei sorgenti all’interno di un repository. Ogni conferimento da parte degli sviluppatori scatena un processo di build automatizzata al fine di rilevare prematuramente eventuali errori di compilazione. Il successo della build in genere avvia l’esecuzione di test automatizzati sul prodotto. Se l’intera procedura va a buon fine, opzionalmente viene generato il pacchetto che rappresenta una nuova versione del software. Tale pacchetto può essere rilasciato sia in ambienti di test sia reso disponibile al cliente finale.

La domanda che è stata posta a riguardo è: qual è il fine ultimo di avere una “catena” simile? Per dirlo in altre parole, cosa non può mancare affinché la CI fornisca tutto il proprio valore?

Uno degli obiettivi primari della CI è avere feedback rapidi, che possono provenire sia dai tester che dai clienti finali. Prima giungono responsi in seguito a un nuovo rilascio, prima si possono aggredire eventuali problemi, come bug, errori o regressioni.

Senza test non esiste DevOps!

Per poter essere efficace, qualsiasi sistema di Continuous Integration non può esistere senza prevedere una adeguata strategia di testing. D’altronde, senza la presenza di test affidabili, non si potrebbe avere alcuna garanzia in merito alla qualità di ciò che il processo automatizzato produce in output. Ciò implica che i test dovrebbero essere anch’essi automatizzati.

Nell’implementazione di pratiche DevOps, può accadere di trascurare in toto o in parte l’importanza dei test, magari perché percepiti come inutili o costosi dal management, o perché mediamente complessi da implementare, soprattutto quando si parla di Unit Test. Talvolta l’effort percepito è più alto del costo reale, per cui si preferisce risparmiare sulla scrittura di test automatizzati, spendendo magari dieci volte tanto in risorse umane impiegate per fare clic sull’interfaccia, ossia test manuali.

E’ bene precisare che qualsiasi tipologia di test ha una propria utilità che non si vuole assolutamente sminuire in questo contesto. Il messaggio da recepire è che i test automatizzati hanno ben più valore, come indicato nel modello della Test Pyramid, e pertanto andrebbero favoriti come investimento proficuo nel medio/lungo termine.

Microservizi e… unicorni.

Un altro prodotto molto in voga come risultato di un processo guidato da DevOps sono i microservizi, paragonati più volte nel corso della giornata agli unicorni: se ne parla spesso, piacciono pure ma nessuno li ha mai realmente visti. 😊

Le critica nemmeno troppo velata si riferisce a quelle soluzioni software spacciate commercialmente come “micro services”, ma che in realtà non lo sono.

La denuncia è che i presunti microservizi siano spesso realizzati senza rispettare i dovuti crismi. Essi devono essere indipendenti, di piccole dimensioni e affidabili. Spesso invece ci si ritrova tra le mani soluzioni che sono banali “rebrand” del vecchio approccio SOA.

Uno dei fattori maggiormente trascurati è proprio quello dell’affidabilità intrinseca del singolo servizio, che diviene ancora più fondamentale quando invocato da altri servizi per soddisfare una richiesta.

Rendere un servizio “reliable” significa riuscire a gestire anche le situazioni in cui uno degli altri servizi restituisce errori, o risulta irraggiungibile, continuando a mantenere un elevata velocità nel fornire risposte ai client.

Nell’ambito della piattaforma Microsoft .NET (nelle versioni “tradizionale” e “Core”) è possibile usare Polly, una libreria che permette di rendere resiliente e “fault tolerant“ una parte di logica sviluppata in C# o VB.NET, implementando diverse strategie. Ad esempio, adottando il pattern Retry abbiamo la facoltà di ripetere una chiamata (o qualsiasi altra operazione) per un certo numero di volte prima di alzare definitivamente bandiera bianca; in alternativa, usando Circuit Breaker possiamo invece sopperire ai timeout persistenti di un servizio remoto restituendo immediatamente un errore. L’obiettivo è quello di garantire una velocità ottimale e costante di risposte al secondo.

A proposito, se volete mettere “alla frusta” la vostra Web API per verificare come si comporta in situazioni di stress, potete usare il tool Locust.

Azure DevOps Services

La piattaforma cloud maggiormente citata nel corso di DevOps Heroes 2019 non poteva essere che Microsoft Azure. In particolare, si è parlato molto dei servizi cloud esplicitamente dedicati alle pratiche DevOps, ossia Azure DevOps Services.

Si tratta di una piattaforma di servizi, disponibili in cloud ma anche on-premise, dedicati sia agli sviluppatori sia agli altri membri del team, dalla pianificazione delle attività allo sviluppo vero e proprio, dalla condivisione del codice sorgente alla gestione di tutti gli automatismi volti a fornire tutto quello che serve per la realizzazione e la distribuzione di software.

Molte sessioni hanno mostrato implementazioni personalizzate di processi DevOps sfruttando questa piattaforma, costruendo ad esempio delle pipeline di comandi per eseguire le build del software, o illustrando un esempio di flusso di lavoro basato sulle feature di ADS.

Il prodotto si è dimostrato molto versatile e capace di adattarsi a diversi scenari: ogni azienda tende a specializzare in modo estremo il proprio workflow, in base alle proprie esigenze e alle persone che costituiscono il team di lavoro.

Un altro punto a favore è l’estrema apertura verso l’integrazione di sistemi esterni, ad esempio SonarCloud. In breve, oltre a una personalizzazione spinta delle politiche di funzionamento, Azure DevOps può colloquiare con eventuali servizi esterni. In questo modo è possibile aggiungere tutto ciò che la piattaforma non è in grado di gestire.

Se si vuole dare un’occhiata e sperimentare con i servizi di Azure DevOps, Microsoft fornisce diversi piani alcuni dei quali gratuiti, per poter iniziare con una dotazione minima e provare con mano senza spendere nulla.

Conclusioni

Nonostante un piccolo cambio di programma dovuto a un’assenza imprevista, l’organizzazione di DevOps Heroes 2019 è stata pressoché impeccabile. Tempi rispettati, nessun intoppo particolare, cibo e caffé abbondanti, argomenti variegati: tutto si è svolto nel migliore dei modi.

Da alcune sessioni mi sarei aspettato forse un approfondimento maggiore, ma è probabile che non fosse possibile, sia per via del tempo ristretto sia per la vastità del tema, che ha davvero tante sfaccettature.

Per un “novizio totale” della DevOps come me, l’occasione è stata comunque utilissima per iniziare a toccare con mano la filosofia e le sue prerogative. Il termine DevOps e il movimento che rappresenta, inizialmente più fumoso, ha assunto un significato più chiaro e delineato. Interfacciarsi a un team che adotta queste pratiche o abbracciarlo direttamente è un compito meno arduo da oggi.

Continuerò senz’altro ad approfondire le mie conoscenze su DevOps, auspicando una nuova edizione dell’evento. Nel frattempo ci si rivedrà presto all’Università di Parma nel prossimo appuntamento in programma: il SQL Saturday #895. 😉