La modernizzazione del software, in particolare nelle organizzazioni articolate, richiede oggi un approccio nel quale è centrale il DevOps release management.
Nel corso degli anni lo sviluppo delle attività si è evoluto grazie al successo delle piattaforme applicative. Il termine “piattaforma” può essere applicato a svariate situazioni, come le soluzioni da ufficio o la finanza. Con questo termine, Sorint.lab intende un gruppo di applicazioni che operano nello stesso ambito, ricevendo enormi benefici dall’innovativo approccio DevOps, che affronta il ciclo di vita del software fondendo i team di sviluppo e di operation.
Sorint.lab si rivolge a un universo di aziende medio/grandi, per le quali imposta e gestisce un ciclo di vita del software e un change management moderno e orientato al futuro. Fulcro centrale di questa attività è proprio il release management.
Nello sviluppare un nuovo progetto, una prima distinzione riguarda il grado di maturità dell’azienda nei confronti dello sviluppo del software. La differenza è tra le aziende che hanno una cultura e/o degli strumenti già attivi da molto tempo, e tra le organizzazioni che hanno mano libera nell’architettura da sviluppare.
Nel primo caso si definisce un approccio incrementale che parta da ciò che c’è e via via evolva verso un approccio moderno.
Nel secondo caso, invece, si definisce un workflow e lo si automatizza.
Il primo caso si verifica frequentemente, ma dopo un primo assesment lo si indirizza verso una strutturazione che via via diventa simile al secondo caso.
Un caso di studio: piattaforme per una banca
È molto frequente trovarsi direttamente nel secondo caso, dove l’azienda si mette nelle condizioni di massima libertà.
Un caso reale affrontato da Sorint.lab riguarda una grande banca italiana che ha deciso di rivedere il modo di pensare, realizzare e rilasciare software. Sono state sviluppate 8 piattaforme, un numero elevato che misura la dimensione della banca in oggetto. Ciascuna piattaforma è composta da un certo numero di microservizi che a loro volta si basano su librerie home-made. La modalità di rilascio è di tipo “assisted continuous delivery”: ciascuna piattaforma prevede un nuovo rilascio ogni 15 giorni, ed essendoci 8 piattaforme si ha un nuovo rilascio ogni due giorni circa.
In questo articolo vediamo cosa succede nel secondo caso, quello nel quale si parte da zero.
DevOps da onboarding a versioning
Nel tradizionale approccio allo sviluppo del software, la parte centrale era un documento altrettanto tradizionale che di fatto sanciva anche la separazione tra attività dev e attività ops, impedendo il rilascio in continuous integration and continuous delivery, in breve CI/CD.
Con l’approccio DevOps questa separazione è stata eliminata, senza però perdere la traccia di ciò che viene fatto. Certo non c’è più un documento complessivo, ma quelle informazioni sono divise in due parti: l’iniziale documento di onboarding e il documento dei versioning incrementali (con relative indicazioni di responsabilità).
La centralità del devops release management
Il DevOps release management si occupa della governance, che consiste nell’assicurare una collaborazione coordinata, semiautomatica e verificabile, tra dev e ops. L’obiettivo finale è l’accelerazione della delivery, sempre documentata e controllata.
Per ottenere i risultati auspicati bisogna realizzare un completo ciclo di collaborazione che assicuri tutte le fasi, anche ricorrendo all’automazione. La comunicazione e il rilascio devono avvenire in modalità informatica, non come nel passato quando mancava un sistema integrato e gran parte dei contatti avveniva per e-mail, o telefonicamente.
Nell’esperienza di Sorint.lab, però, l’avvio del progetto viene meglio sviluppato con uno o più incontri in presenza, o al più in video. È qui che si precisano obiettivi e funzioni. In linea teorica anche una o più fasi di avvio possono essere sviluppate con strumenti collaborativi asincroni e non in presenza, ma è ragionevole pensare che non sia questa la strada per ottenere i risultati migliori.
La multi-pipeline è servita
Una volta stabiliti obiettivi e funzioni si può passare all’implementazione del workflow di sviluppo e rilascio concordato. Sorint.lab implementa soluzioni e processi altamente ingegnerizzati affinché l’utilizzo finale sia semplificato e guidato. La prima fase è l’onboarding di nuove applicazioni/microservizi che si traduce nel censimento delle specifiche di progetto in un file dedicato e versionato. Nella seconda fase, a seconda delle configurazioni, viene attivata una pipeline con gli opportuni linguaggi, workflow, automazioni e tutto ciò che è richiesto per lo specifico progetto.
Il contatto tra dev e ops viene implementato con due strumenti essenziali: uno spazio di condivisione per gli step che portano alle approvazioni e uno strumento di controllo che svolga test automatici end-to-end. Una parte rilevante dei KPI di progetto viene raccolta e confrontata in questa fase. Al termine del ciclo, la specifica release viene approvata (OK) o rigettata (KO), con il rollback alla versione precedente. E il gioco è fatto.
Conclusioni: competitività oggi e domani
L’evoluzione del software porta a sistemi informativi suddivisi in piattaforme complete alle quali affidarsi dall’inizio alla fine dello specifico compito. Il passaggio da soluzioni monolitiche a piattaforme tailor-made passa per la suddivisione di ciascuna piattaforma in microservizi, componenti facili da maneggiare e per i quali viene richiesto un costante aggiornamento che non crea problemi all’attività degli altri servizi. Il DevOps release management si occupa della governance del processo di sviluppo continuo, tenendo sotto controllo i risultati che impattano l’attività presente e quella futura.