Development da un lato e Operations dall’altro, il DevOps è una metodologia di sviluppo del software che sfrutta le nuove logiche della condivisione e della collaboration ma anche di un crowdsourcing più verticale. L’obiettivo? Accelerare i tempi di rilascio del software di cui le aziende non possono più fare a meno. Come? Portando nuovi livelli di condivisione e di integrazione tra gli sviluppatori e gli addetti alle operations per accelerare i tempi di progettazione, testing e di rilascio delle soluzioni applicative aziendali sia in ambienti tradizionali che in ambienti cloud. Il tutto assicurando la qualità e la sicurezza del software sviluppato.
Cosa vuol dire DevOps?
Uno dei modelli di riferimento del DevOPS è il cosiddetto CALMSS, acronimo di Culture, Automation, Lean, Management and Measurement, Sharing and Sourcing. Ed è proprio questo a definire cosa è il DevOps. Il DevOps, infatti, è un set di pratiche e di cambiamenti culturali supportati da strumenti automatici e processi di Lean Management, che consente di automatizzare il rilascio del software rispetto alla sua catena di produzione, permettendo alle organizzazioni di poter contare su un software e applicazioni di qualità superiore e sicura in modo estremamente più rapido, per accontentare i clienti nel modo migliore e più rapidamente. Come raccontano gli esperti, ci sono molti strumenti, competenze ed elementi comuni, tra una realtà DevOps e un altra. Fare in modo che uno o più di questi entri a far parte integrante del processo di sviluppo aziendale è un buon inizio per velocizzare i tempi di rilascio dei codici e creare sistemi più flessibili e sicuri.
Certo è che chi si fregia della qualifica di DevOps non è detto né che sia uno sviluppatore capace anche di coprire l’aspetto più operativo della programmazione, né che un esperto Ops abbia imparato anche a sviluppare codice. Il fatto è che il Devops presuppone che in azienda ci sia un team interfunzionale, dove ognuni risorsa è responsabile di tutto. In ambito aziendale oggi comunque è ancora molto raro trovare un’organizzazione che possa qualificarsi come un negozio DevOps a tutto campo. Piuttosto, si tende a trovare una squadra DevOps, allineata con applicazioni specifiche, come ad esempio un team specializzato nel mobile, un altro specializzato nel checkout e via dicendo.
Non è tutto DevOps quello che si racconta
A muovere le aziende verso questo nuovo modello di lavoro il fatto che molti professionisti ICT lavorano in ambienti configurati per silos, e cercano sistemi più veloci e affidabili a supporto del loro lavoro. Ma come agevolare la messa in produzione del software?
Introducendo una strategia DevOps è possibile effettuare test e implementare nuove funzionalità e applicazioni molto più rapidamente rispetto alle modalità di sviluppo tradizionali, senza contare il fatto che gli stessi sviluppatori, lavorando in prima linea sulla programmazione, sono stimolati a scrivere codici di qualità superiore.
A questo punto la domanda è un’altra: come si fa, dunque, a portare il DevOps in azienda? Prima di tutto bisogna capire cosa significa DevOps. La maggior parte delle definizioni, infatti, risulta sempre piuttosto generica, focalizzandosi su linee guida teoriche: sviluppo più rapido, verifiche più frequenti, automazione, collaborazione… Ma questo ancora non è sufficiente a far cogliere le opportunità di questo approccio, di come si presenta un negozio DevOps e come funziona. Può infatti capitare che un team IT si dichiari tale solo perché nella sua filiera di produzione integra un paio di processi, il che è ancora molto lontano da ciò che dovrebbe essere un negozio DevOps.
La metodologia è fondamentale: il lato Agile del DEV
Il DevOps è una medaglia a due facce. Sul fronte dello sviluppo in un ambiente DevOps la base è la metodologia di lavoro prescelta. Detto questo, un ambiente DevOps non può non fare riferimento alla metodologia Agile, e cioé a quella summa di principi derivati dal “Manifesto Agile” che nel 2001 ha definito un modello di sviluppo focalizzato sull’obiettivo di consegnare al cliente, in tempi brevi e frequentemente (early delivery – frequent delivery), software funzionante e di qualità. Rispetto ai metodi tradizionali a cascata o ad altri processi software, le pratiche Agile presuppongono la formazione di team di sviluppo piccoli, cross-funzionali e auto-organizzati, lo sviluppo iterativo e incrementale, la pianificazione adattiva e il coinvolgimento diretto e continuo del cliente nel processo di sviluppo.
Se si vuole mettere in piedi un IT shop di successo, il primo passo è dunque quello di scegliere una metodologia Agile intuitiva, con dei framework di sviluppo come Scrum (che enfatizza tutti gli aspetti di gestione di progetto legati a contesti in cui è difficile pianificare in anticipo) o KanBan (che aiuta a visualizzare e rendere esplicito il flusso di lavoro per riconoscere prima le opportunità di miglioramento, limitando il work in progress). Questi framework sono importanti perché aiutano i team di sviluppo a definire rapidamente gli obiettivi e le priorità, ad assegnare i compiti e a identificare dove possono verificarsi problemi nello sviluppo di un processo.
Automazione & Opensource: un binomio ad alta velocità
Un’altra caratteristica fondamentale di un sistema di sviluppo DevOps sono l’integrazione continua (CI) e l’erogazione continua e/o la distribuzione continua (CD). CI significa che nel processo di sviluppo i test su una porzione di codice sono continui e automatici, mentre CD significa che il processo di messa in produzione del codice validato dopo il dovuto collaudo diventa automatica. È così che si accelerano i tempi di rilascio.
In passato, ad esempio, molte aziende metteva in produzione il nuovo codice ad orari prestabiliti. Ma la velocità del business ha reso questo modello per cicli di rilascio piuttosto obsoleto e in antitesi al DevOps che, invece, punta proprio ad automatizzare il ciclo di rilascio per renderlo il più possibile immediato.
La connessione con il cloud
I DevOps hanno un ruolo chiave anche nel cloud. Le aziende che hanno un’infrastruttura cloud, infatti, hanno costantemente bisogno di gestire una serie di risorse e di capacità che possono essere risolte dai DevOps. Il cloud in chiave DevOps non ha bisogno di essere basato né su AWS né su cloud pubblico. Deutsche Telekom HBS, ad esempio, usa AWS per le risorse di sviluppo ma ha costruito un cloud privato interno basato su Citrix CloudStack e VMware per il suo ambiente di produzione, usando Jenkins per l’integrazione continua, script fatti in casa, configurazioni Chef archiviate in GitHub e servizi di Ravello per creare sandbox di sviluppo della produzione su AWS.
Tuttavia, le imprese che stanno aprendosi al DevOps lottano contro le infrastrutture legacy, che non sempre sono in grado di interfacciarsi con i moderni strumenti di automazione delle infrastrutture né, tanto meno, con le situazioni di private cloud.
