Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Che cosa significa DevOps e perché oggi è un fondamentale della programmazione

pittogramma Zerouno

SOFTWARE

Che cosa significa DevOps e perché oggi è un fondamentale della programmazione

03 Ott 2016

di Laura Zanotti da Digital4

Crescono applicazioni e sistemi a supporto del business. Il time to market è tiranno e agli sviluppatori si chiede maggiore velocità nella messa in produzione di software e di app. L’approccio DevOps è un modello secondo cui team di sviluppo interfunzionali programmano in maniera più rapida, rilasciando soluzioni di qualità e sicure per ambienti tradizionali e in cloud

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 azineda 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.

Il codice, infatti, con il Devops è conservato in un repository di sorgenti che viene utilizzato come archivio ma anche come fonte per controllare le varie versioni. Quello di Git (un sistema di controllo versione che serve a registrare i cambiamenti che si fanno su un file o su una serie di file nel tempo, così da poter richiamare una versione specifica di quei dati in qualsiasi momento) è superiore anche a molti repository opensource, avendo sistemi di controllo più evoluti rispetto, ad esempio, ai meno recenti Concurrent Versions System (CVS) o Apache Subversion.

Scritto nientemeno che da Linus Torvalds, il padre di Linux, Git è nato in risposta a un bisogno della comunità opensource che chiedeva un sistema decentrato a cui gli sviluppatori di tutto il mondo avrebbero potuto comodamente accedere. Come sottolieano gli esperti, si tratta di uno strumento decentralizzato funziona bene anche in azienda, dove le squadre di sviluppo possono essere distribuite tra più divisioni e tra più sedi geografiche differenti.

Le versioni in commercio di Git offrono diversi add on che permettono di gestire collaboration, processi e sistemi di validazione, IDEs (Integrated Development Environment), CI/CD e strumenti di Test.

IaaC, ovvero Infrastructure As a Code

Il codice del software non è l’unico elemento archiviato nel repository di Git. Sempre più spesso, infatti, vengono memorizzati anche gli script che contengono tutti i dettagli delle configurazioni e i modelli creati con gli strumenti di gestione della configurazioni come, ad esempio, Puppet e Chef, che sono due tra i linguaggi più popolari.

La generazione di metodi automatici per configurare e implementare l’infrastruttura ha dato origine al concetto di infrastructure as a code (IaC). Rally Software, ad esempio, è un fornitore di software per il project management d’ispirazione Agile che ha dedicato un anno e mezzo di lavoro nella creazione di configurazioni basate su Chef per i suoi servizi più importanti, sviluppati su 60 host VmWare e istanze AWS (Amazon Web Services).

“La maggior parte della configurazione è stata fatta manualmente – ricorda Jonathan Chauncey, ingegnere software di Rally Software – il che ha reso il lavoro molto più impegnativo, soprattutto quando si deve scalare rapidamente. Senza contare tutti i problemi connessi al debug coinvolge un gruppo di server”.

Gli ingegneri di Rally Software, hanno forti competenze anche sulla programmazione Ruby. La scelta di Chef come strumento di gestione della configurazione, ha consentito alla società di trovare un valido sistema per installare rapidamente il software. Ma Chauncey sottolinea anche come questa metodologia sia efficace anche per scrivere modelli per tutti i sistemi, non solo per i servizi Web o l’indotto dei microservizi.

“Quando si tratta di infrastrutture non bisogna illudersi – ha ironizzato il manager -. Se l’infrastruttura muore alle due di notte ed è necessario ricostruirla, quanto puoi contare sulla tua squadra di sviluppo a quell’ora?”

Nello specifico, avere un’infrastruttura come codice significa che questa può essere incorporata in altri processi DevOps, sia per le fasi di test che per la messa in produzione. Rally Software memorizza tutte le sue configurazioni infrastrutturali nel repository GitHub, testate e distribuite in modo continuo esattamente come il resto dei processi di integrazione e implementazione continui processati decine di volte al giorno. Che si tratti di codice del software o di infrastrutture, tutto passa dalla stessa metodologia automatica di processo, Indipendentemente da ciò che viene modificato.

“Un altro vantaggio delle IaC è che si può contare su soluzioni ever green – ha aggiunto Alain Gaeremynck, manager DevOps nonché enterprise architect presso la canadese Yellow Pages Group – dal momento che è possibile mantenere sempre aggiornati alle ultime versioni sia i sistemi che i pacchetti. Noi abbiamo sposato la causa IaC. Una volta impiegavamo tempo e risorse nel costruire infrastrutture da monitorare costantemente e da aggiornare. Oggi, invece come parte del processo di generazione lavoriamo così: distruggiamo e ricostruiamo ex novo, il che ci permette di introdurre aggiornamenti Java o sviluppare per l’ultimo sistema operativo immesso sul mercato, ad esempio, perché in ogni caso passiamo da un ciclo QA”.

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.

“Per me, un prerequisito di un DevOps è che sappia sfruttare al meglio le risorse a seconda delle necessità – ha commentato Ram Akuka, direttore della divisione DevOps presso Deutsche Telekom HBS, un fornitore di servizi di telefonia per le Pmi – e di separare l’infrastruttura dal quello che è la centrale di servizio. La nostra divisione DevOps supporta moltissimo l’attività interna aziendale”.

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.

Alcuni operatori specializzati nell’automazione di infrastrutture come, ad esempio, QualiSystems o CFengine stanno focalizzandosi sulla gestione delle infrastrutture legacy che soluzioni del calibro di OpenStack non supportano ancora (se mai lo faranno).

CFengine in grado di automatizzare tutto ciò che può includere un agente integrato – ha affermato Mahesh Kumar, VP of marketing di CFengine -. Nel caso non lo avessimo ancora, siamo in grado dicompilare un agente per quella piattaforma, modificandolo in corso d’opera”.

Esistono IT Shop DevOPs capaci di sviluppare soluzioni intelligenti per le infrastrutture legacy, come ad esempio la scrittura di un livello API pere tradurre azioni specifiche. Anche nel caso abbiate soluzioni EMC con un numero di attacchi limitati, i DevOps vi aiuteranno a non buttar via nulla, trovando la soluzione giusta attraverso una nuova modalità di programmazione.

Laura Zanotti da Digital4
Giornalista

Ha iniziato a lavorare come technical writer e giornalista negli anni '80, collaborando con tutte le nascenti riviste di informatica e Telco. In oltre 30 anni di attività ha intervistato centinaia di Cio, Ceo e manager, raccontando le innovazioni, i problemi e le strategie vincenti delle imprese nazionali e multinazionali alle prese con la progressiva convergenza tra mondo analogico e digitale. E ancora oggi continua a farlo...

Argomenti trattati

Approfondimenti

A
Api
D
Devops
S
Sviluppo Software

Articolo 1 di 5