DevOps, Innanzitutto cerchiamo di definire l’origine della parola, che in realtà è il risultato della fusione per contrazione di due termini, development e operations. Già questo può aiutarci a intuire il significato di questo concetto, che riguarda sia la figura professionale del developer che quella del sistemista, e più precisamente tenta appunto di creare un link tra queste due professionalità, proponendo quindi nuove forme di collaborazione e metodologie di sviluppo innovative che mirano ad azzerare, o quanto meno a diminuire le frizioni tra due ruoli spesso in contrasto. In realtà il concetto di DevOps è più ampio, infatti ci si può riferire anche all’integrazione non solo dei task dei dev e dei sysadmin, ma anche ad altre professionalità, ad esempio i network engineer con i DBA e via discorrendo…
Come molti avranno rilevato a proprie spese, tra developers e sistemisti possono nascere forti attriti dati fondamentalmente dalla naturale differenza di vedute. La prima finalizzata alla creazione di nuovi prodotti (innovazione e dinamismo) la seconda più orientata invece a al mantenimento ed alla messa in sicurezza degli stessi (stabilità). E’ quindi evidente che le due professionalità sono intrinsecamente portate allo scontro, con un impatto più o meno devastante.
Come è quindi possibile cercare di avvicinare il lavoro di developers e sistemisti, quello di creazione e rilascio di nuovi prodotti e le funzioni di controllo qualità, testing, configurazione e mantenimento? Sicuramente fino a qualche anno fa una collaborazione così stretta non sarebbe stata tecnicamente possibile, ma le ultime innovazioni tecnologiche quali i concetti di cloud computing e la virtualizzazione, gli strumenti di project management unificato, e sistemi di versioning avanzati, hanno finalmente reso possibile un’interazione più stretta da entrambi i lati. Questi strumenti rendono infatti la possibile la collaborazione tra team diversi, la condivisione degli obiettivi primari e delle problematiche riscontrate, rendendo immensamente più gestibile la risoluzione di errori e bug.
Oltre alle nuove tecnologie di cui abbiamo parlato, negli ultimi anni sono mutate le esigenze di sviluppo SW, che richiedono tempistiche sempre più stringenti, al fine di abbassare il cosidetto “time to market”. Se pensiamo che oggi grazie ai tool precedentemente citati chi si occupa del deployment può vedere in tempo reale e on demand lo svolgimento del lavoro di chi si occupa di development, può quindi settarne agevolmente le milestones, può testare un’applicazione in un virtual server con determinate specifiche e riferire agli sviluppatori i problemi da affrontare in pochi minuti, capiremo facilemnte che il pradigma classico dello sviluppo software sta vivendo un’evoluzione senza precedenti.
DevOps: i processi fondamentali
I processi chiave che caratterizzano le metodologie DevOps sono quindi:
Cloud e Virtualizzazione: la necessità di avere a disposizione servizi e strumenti che offrono una modalità veloce di verifica e gestione della complessità di un’applicazione. Esempi di tali strumenti sono le API di cloud provisioning quali Amazon EC2, o servizi SaaS quali New Relic e Loggly, che offrono capacità operazionali cloud, oppure strumenti di gestione della configurazione quali Chef e Puppet.
Continuous Delivery: Significa rilasci e miglioramento continuo, significa testing agile ad ogni modifica, significa mettere l’accento sul prototyping e sullo user testing delle nuove feature. Le attività prettamente ingegneristiche coinvolte per assicurare uno sviluppo che segue i dettami della “continuous delivery” sono: controllo codice sorgente, versioning, integrazione continua, testing di unità e testing integrato e deployment automatizzato.
Dietro questa cura maniacale della parte organizzativa e della fase di testing c’è l’idea che sia meglio affrontare nella realizzazione di un prodotto tanti piccoli cambiamenti (continui) innescati dal dialogo costante tra sviluppatori e sistemisti, che non dover validare un’intera applicazione solo alla fine di un’intero ciclo di sviluppo, o peggio ancora offrire al mercato un prodotto di cui non abbiamo adeguata certezza sull’assenza di bug e qualità del funzionamento. Quest’ultima pratica, particolarmente deleteria porta poi a sostenere costi di supporto al cliente che in passato hanno costituito la causa maggiore del collasso di business IT.
