La trasformazione digitale coinvolge numerosi aspetti, spesso strategici, nella vita di un’azienda. Questo post non è puramente tecnico. Semplicemente rappresenta una serie di riflessioni sull’implementazione della metodologia DevOps. Una sorta di appunti e considerazioni che ho raccolto nelle ultime attività di consulenza.
Tutti gli anni nel periodo di Agosto, posto alcune considerazioni legate alle attività lavorative che mi hanno impiegato negli ultimi mesi. Quest’anno è un anno particolare, per diverse ragioni, legate prevalemente ad attività di sviluppo effettuate in smart-working, ore dedicate al training ed all’ottenimento di certificazioni. Il focus sul lavoro è stato dedicato fondamentalmente ad un 50% di lavoro ad integrazioni e nuovi sviluppi, ed un 50% all’implementazione di CI/CD e flusso di lavoro con metodologia DevOps. E proprio di questa metologia e della sua applicazione, voglio parlare.
Alla base di tutto: la metodologia agile. Impostando un sistema di sviluppo software basato su metodologia Agile vengono coinvolti numerosi stakeholder, partendo dalla dal product management arrivando a figure, apparentemente marginali, come gli addetti alla documentazione.
Il tutto strutturato attraverso brevi cicli di sviluppo, focalizzati su task ben definiti, raggruppati sotto forma di stoire (spesso dei veri e propri obiettivi definiti dagli utenti).
Parallelamente alla metodologia agile, si è imposta la metodologia DevOps, che apporta un’integrazione tra sviluppatori, sistemisti, stakeholder e tutte le altre entità coinvolte nello sviluppo. Inoltre, impone l’adozione di una serie di strumenti di comunicazione tra i diversi gruppi.
La comunicazione! La comunicazione rappresenta un elemento fondamentale per il successo dell’adozione di DevOps nel ciclo di vita dello sviluppo. Ho visto teams di sviluppo per mancanza di comunicazione e soprattutto di documentazione del codice prodotto. Talvolta, la ricerca all’interno dell’azienda di documentazione tecnica, analisi e raccolta dei requisiti diventa una vera e propria impresa.
Ho visto azienda con commesse importanti, non avere documentazione e delegare l’analisi tecnica a single persone (che diventano single point of failure). Il sistema di sviluppo “basta che funzioni” è molto lontano dall’approccio di sviluppo con metodologie Agile e DevoOps. Attenzione, perchè questo tipo di approccio è purtroppo ancora troppo diffuso.
Ma quali sono i vantaggi del passaggio alla metodologia DevOps?
E’ questa la prima domanda che mi viene posta. Insieme a “funziona veramente?”. Solitamente, la risposta può essere sintetizzata nei seguenti punti:
- minor tempo per il refactoring del codice
- minor tasso di fallimento
- minori tempi di ripristino
- un numero maggiore di deployment nell’arco temporale
- migliore tempo di risposta ai cambiamenti
Per poter velocizzare l’introduzione di DevOps, può essere molto utile portare esperienze personali e, se possibile, portare dei veri casi di successo.
Non è tutto oro quello che luccica! Senza un giusto approccio alla metodologia DevOps, il fallimento è assicurato!
Sviluppo con tecnologie moderne?
Un altro elemento fondamentale per affrontare un cambiemento tecnlogico, rigurda un’attenta analisi delle tecnologie attualmente in uso, evidenziando quelle che effettivamente dovranno essere mantenute e quelle che dovranno essere sostituite. Mi è capitato piuttosto spesso di trovare tecnologie obsolete ancora utilizzate. Sviluppatori pigri e abituati ad utilizzare anche jquery all’interno delle loro pagine html. Per non parlare della mancanza dell’utilizzo di veri e propri framework dedicati come ad esempio Angular, React e il piu’ recente Blazor.
Uno degli aspetti che piu’ maggiormente rappresenta una svolta nell’impostazione del flusso di lavoro è rappresentato dall’introduzione dei container. Negli ultimi sei mesi ho dovuto lavorare parecchio con questa tecnologia e con docker. L’introduzione di docker, dei container e dei repository privati consentono di implementare rapidamente soluzioni deployabili dai sistemisti in maniera rapida. La pubblicazione di applicazione utilizzando docker ed i containers consente di velocizzare la pubblicazione all’interno dei vari ambienti in pochi minuti. Tradiziolmente questo tipo di operazioni coinvolgevano sistemisti e molte volte erano operazioni da effettuare manualmente. Se, oltre all’utilizzo della “dockerizzazione” vengono anche introdotte pipeline CI/CD, la compilazione e la pubblicazione delle immagini si riduce al push su repository git.
Lo sviluppatore e i container
L’utilizzo dei container non è dedicato solitamente limitato agli ambienti server. Docker è disponibile anche per ambienti “personal”: ad esempio è possibile la versione desktop che può essere eseguita all’interno di ambienti Linux, Mac e Windows. Inoltre, Docker Desktop integra all’interno una versione di Kubernetes, utilizzabile con minikube.
L’introduzione dei container consente di impostare il supporto di cicli di sviluppo rapidi e se integrati con pipeline di realizzare infrastrutture parzialmente (ma anche totalmente) indipendenti dalla presenza dei sistemisti. Personalmente, ho assistito alla pubblicazione di soluzioni in tempi ridotti, passando da rilasci con cadenza settimanale a cadenze giornalieri.
Gestione dei carichi con i cluster
Nel processo di pubblicazione dei container spesso si ha la necessità di utilizzare sistemi di orchestrazione. Il più diffuso, e soprattutto quello su cui ho lavorato nell’ultimo anno è Kubernetes.
Kubernetes consente di definire la parte infrastrutturale e di gestione dei container. Utilizzando un’ approccio alla configurazione basato su file .yaml è possibile definire strutture anche piuttosto complesse ed orchestrarne le funzionalità.
L’implementazione di un cluster utilizzando Kubernetes consente di definire l’architettura utilizzando file di configurazione che possono essere inseriti all’interno di git butcket. Le operazioni di configurazione delle repliche, scaling e definizione dei volumi, tipicamente delegata ai sistemisti è ora integrata nel flusso CI/CD.
Evidentemente, l’introduzione dell’automazione e dell’orchestrazione coinvolge sistemisti e programmatori, rendendo molto spesso l’intero ciclo di sviluppo e di deployment una cosa sola.
Container, Kubernates e… CI/CD
A completare l’intero ciclo di sviluppo in aggiunta ai container e a Kubernetes, sono le pipeline CI/CD. La loro introduzione consentono ai team di sviluppo di implementare applicazioni che richiedono cambiamenti frequenti e soprattutto affidabilità nella loro pubblicazione.
A completamento del flusso è necessario utilizzare un sistema di versioning del codice, spesso un sistema basato su GIT.
All’interno della pipeline vengono definiti i processi (e spesso anche le tecnologie) per la creazione di codice il piu’ possibile ottimizzato, aumentando la qualità del prodotto generato e automatizzando le operazione di deployment. Solo quando verrà definita e implementata una pipeline solida e funzionamento sarà possibile trarre vantaggio dalla velocizzazione dei task da eseguire.
Molto spesso, l’utilizzo della pipeline passa dall’integrazione con docker e kubernetes: in container permettono di realizzare le applicazioni e di “pacchettizzarle”, mentre Kubernetes consente di metterli in esecuzione, ad esempio bilanciandone il carico.
Continuos Integration e Continuos Delivery
La CI consente agli sviluppatori di sviluppatore codice con frequenti cambiamenti, frequenti iterazioni e frequenti controlli all’interno di un repository, verificando eventuali cambi di versione. L’utilizzo di un sistema di versionamento del codice, come ad esempio GIT, consente al team di sviluppatori di gestire il meccanismo di integrazione e convalida del sorgente.
Utilizzando la CI ogni sviluppatore preleva e pubblica il sorgente frequentemente all’interno del repository. I cicli di commit sono spesso molto brevi: questa tecnica consente di diminuire la probabilità che uno sviluppatore modifichi lo stesso codice, ed evitando eventuali fusioni durante i commit.
La CI consente di definire regole di automatizzare lo sviluppo, la creazione di pacchetti ed il testing delle applicazioni. Il tutto configurato tramite la pubblicazione all’interno di branch con particolari tag.
Proprio come un pipeline, al termine del processo della CI inizia quella della delivery. Si tratta in pratica del processo di pubblicazione dell’applicazione verso l’ambiente di rilascio. Tipicamente sono presenti almeno due ambienti di rilascio: l’ambiente di staging e l’ambiente di produzione. Lo staging consente di pubblicare la “preview” dell’applicazione intermedia e di renderla disponibile per i test. L’ambiente di produzione che consente di rilasciare la versione definitiva dell’applicazione. Il tutto tramite script di automazione, che consentono di interagire con eventuali elementi esterni come il riavvio di server web, l’esecuzione di procedure di modifica ai database ecc… In pratica tutto ciò che consente di rendere operativa e disponibile l’applicazione.
Utilizzando CI all’ingresso della pipeline e CD all’uscita, è possibile automatizzare l’intero processo.
Nello strutturare il processo di sviluppo del codice, è fondamentale impostare correttamente l’intero processo CI/CD in modo da realizzare un sistema funzionante e che consenta di effettuare deployment veloci ed affidabili.