TIGPaper_DevOps_170615 Final

DevOps Top
Trends 2015:
Dalla Teoria
alla Pratica
2015
Giugno 2015

© The Innovation Group - 2015 | 1
SI RINGRAZIA PER IL SUO SUPPORTO:
DevOps Top Trends
2015: Dalla Teoria alla
Pratica

SOMMARIO
INTRODUZIONE 3
CHE COS’È E DA DOVE È NATO DEVOPS 3
QUAL È LA PRINCIPALE NOVITÀ DI DEVOPS? 7
COME CAMBIA L’ORGANIZZAZIONE DEL LAVORO CON DEVOPS 11
I BENEFICI OTTENUTI CON DEVOPS 12
LE CRITICITÀ LEGATE ALLA TRASFORMAZIONE 13
LA ROADMAP PER IMPLEMENTARE DEVOPS 14

INTRODUZIONE
Oggi la competitività delle imprese è strettamente legata alla possibilità di utilizzare il
software per imporsi sul mercato con servizi innovativi e con un time-to-market sempre
più stretto. Un elemento accomuna chi riesce in questo intento, che si tratti di un
operatore finanziario, un retailer, una software house o un’industria di prodotti di largo
consumo: aver posizionato l’IT al centro della strategia di differenziazione sul mercato e
aver dotato l’organizzazione IT di persone, processi, strumenti in grado di fornire
l’accelerazione richiesta.
Negli ultimi anni, DevOps si è affermato come la disciplina (fino a pochi anni fa utilizzata
solo da un piccolo numero di precursori, oggi già mainstream e con numerosi casi di
implementazione matura), in grado di “traghettare” le organizzazioni verso un nuovo
modo di concepire l’IT aziendale. Non più separata e ricettiva, ma in grado di
promuovere una trasformazione Digital allineando il business ai risultati dei best
performers nel settore di appartenenza. Grazie a DevOps ogni azienda ha la possibilità di
muoversi con maggiore rapidità, sfruttando tutte le opportunità che possono venire
dalla massimizzazione delle performance IT in termini di nuovi servizi e nuove
funzionalità.
CHE COS’È E DA DOVE È NATO DEVOPS
Con il termine DevOps si intende una metodologia di lavoro che punta alla
comunicazione, collaborazione e integrazione tra sviluppatori e addetti alle operations,
in cui tutti condividono rischi e benefici di un processo di innovazione rapido. In questo
modo il flusso di lavoro pianificato è ad elevato tasso di deployment, e si ha un controllo
e una visibilità maggiori sullo stato di avanzamento delle applicazioni nella pipeline di
rilascio. Il risultato è, oltre a una maggiore affidabilità e stabilità degli ambienti di
produzione, una migliore qualità del software.
Se questa definizione generale è ampiamente condivisa, le successive descrizioni di che
cosa questo implica possono variare. Alcuni vedono DevOps come una conseguenza di
Agile, metodologia molto diffusa in ambito sviluppo che ha portato a interazioni più
frequenti e a rilasci intermedi del software in modo da ottenere un migliore
allineamento con le richieste del business. In realtà le metodologie Agile hanno aiutato
gli sviluppatori ad essere più rispondenti ai requisiti provenienti da manager e analisti
WHAT DOES DEVOPS MEAN?
The term DevOps is commonly considered a combination of the concepts of
development and operations. It is used in IT to refer to roles or processes that bridge
various department - usually development and operations teams - to achieve a
certain project management philosophy that involves more efficiency in
communications between development teams and other parts of a greater business
or organization.
(TECHNOPEDIA, http://www.techopedia.com/definition/13607/devops, 31 – 05 – 2015)
Grazie a DevOps ogni
azienda ha la possibilità
di muoversi con
maggiore rapidità,
sfruttando tutte le
opportunità che possono
venire dalla
massimizzazione delle
performance IT

aziendali, ma non hanno tenuto conto degli aspetti legati alle operation: DevOps invece
risolve questa lacuna avvicinando gli sviluppatori alle operations, con obiettivi di
maggiore collaborazione e condivisione dei risultati finali.
Per altri DevOps è vissuto come la possibilità di automatizzare processi, tipicamente
legati alla messa in produzione del software, che prima erano manuali. Secondo questo
trend gli sviluppatori diventano utenti del proprio software, hanno possibilità di
verificare più rapidamente il funzionamento in ambienti di produzione creati su misura,
codificati e riproducibili. Via via che DevOps si afferma e diventa sempre più popolare
nel mondo IT, ci si rende conto però che le sue implicazioni sono molto più ampie e
hanno impatto sull’intero business, permettendo di raggiungere livelli più elevati di
efficienza e modificando l’organizzazione del lavoro oltre le mura del dipartimento IT.
Se consideriamo quindi la catena del valore delle attività che partono dai bisogni dei
clienti e terminano con il rilascio di nuovi prodotti/servizi, DevOps si posiziona al centro
e coinvolge innanzi tutto sviluppo e operation, ma indirettamente influenza l’intera
organizzazione, che in ultima analisi diventa molto più rapida nella risposta alla domanda
del mercato.

La nascita di DevOps viene tipicamente fatta risalire al 2009 quando Patrick Debois,
programmatore e manager, presenta per la prima volta il concetto alla conferenza Agile
di Toronto. Da allora i contributi, le idee, le collaborazioni in questo ambito sono
costantemente cresciute, fino a portare a un vero e proprio “movimento DevOps”. I
"DevOps Days", iniziati nel 2009 in Belgio, si sono quindi diffusi in ogni parte del mondo,
in India, USA, Brasile, Australia, Europa e anche in Italia.
Tra gli elementi che hanno portato all’affermazione di DevOps abbiamo:
 Alcuni casi di utilizzo dell’approccio DevOps. Sono stati fondamentali per
l’affermarsi di società innovative che avevano come condizione imperativa per la
stessa sopravvivenza in mercati a fortissima crescita la possibilità di rilasci molto
frequenti del software (ad esempio Flickr, Spotify, Netflix, Facebook).
 Il tema dei nuovi sviluppi Mobile. Ha complicato l’esistenza ai team di sviluppo
costringendoli a rivedere i modelli operativi per raggiungere performance più
elevate e contemporaneamente migliorare la qualità del software prodotto.
 La nuova disponibilità di servizi Platform as a service in Cloud, che contestualmente
hanno realizzato un’automazione che riduce i tempi di messa in produzione del
software.
 Ulteriori contributi metodologici, come Lean IT, la filosofia del Continuous
Integration & Release, Agile Infrastructure Thread, Infrastructure-as-a-code
1
.
DevOps is about people. Un punto importante che va sottolineato da subito è che
DevOps rappresenta innanzi tutto un cambiamento di cultura nell’organizzazione, che si
può raggiungere soltanto lavorando sulle persone e sul loro modo di lavorare.
Storicamente gli ambienti di sviluppo e di produzione hanno operato separatamente:
questo è il principale limite che DevOps si propone di abbattere. In anni più recenti la
1
The Convergence of DevOps di John Willis, 2012, http://itrevolution.com/the-convergence-of-devops/

diffusione di ambienti social, il movimento del software open source, la condivisione in
cloud hanno stressato maggiormente rispetto al passato l’importanza dell’integrazione
delle competenze e della collaborazione. Finora nessuno sviluppatore si è mai posto il
problema del deployment, non dovendo risponderne. Anzi, il mondo dello sviluppo e
delle operazione sono separati dall’origine da obiettivi molto diversi. Gli sviluppatori
hanno esigenze di velocità, flessibilità, devono rapidamente passare dall’idea al codice e
alla produzione. Le operation invece richiedono prevedibilità e stabilità. Le due aree
hanno avuto fino ad oggi priorità e obiettivi diversi e questo ha portato tradizionalmente
a incomprensioni, frustrazione di tutti e rallentamento della produzione. Ad aggravare
ulteriormente le cose, gli ambienti di sviluppo e di test sono spesso diversi dalla
produzione, e mancano soluzioni standard per sviluppo, test e produzione.
Poiché spesso il lavoro comprende molte persone (developers, testers, release
managers, sysadmins) se tutti questi operano in silos separati, non collaborano, vedono
solo le proprie attività, il rischio maggiore è che i problemi siano trasmessi da un team
all’altro senza possibilità di risolverli insieme e alla radice.
Tutto questo porta a una serie di problematiche tipiche del mondo dell’Application
development & deployment:
 Rilasci inaffidabili
 Errori e scarsa qualità
 Malfunzionamenti quando il software va in esercizio
 Cambiamenti successivi al software richiesti appena è in produzione
 Perdite di tempo per l’identificazione e la risoluzione dei problemi

 Poco tempo da dedicare al rilascio di nuove funzioni.
In ultima analisi tutto questo si riflette per l’azienda in un aumento dei tempi di rilascio,
una perdita di competitività e di clienti.
QUAL È LA PRINCIPALE NOVITÀ DI DEVOPS?
Il valore più importante di DevOps è che complementa gli sviluppi Agile estendendo e
completando i processi di continuous integration & release verso la produzione,
assicurando che il codice che arriva in produzione sia immediatamente pronto per
essere utilizzato dagli utenti finali o dagli stessi clienti dell’azienda
2
.
In questo modo DevOps abilita un Continuous Delivery, ossia un flusso di lavoro costante
che coinvolge le operation: si evitano così sprechi di tempo, l’accumularsi di deployment,
oltre che arresti e malfunzionamenti del software una volta in produzione. In termini
molto generali si intende con Continuous Delivery un ciclo continuativo di sviluppo, test,
delivery del software in ambienti di produzione. Riportiamo sotto un’altra definizione:
Per accelerare le delivery del software e contemporaneamente incrementare la qualità
dello stesso e l’affidabilità dell’ambiente finale, è necessaria un’accelerazione a ogni fase
del processo e in particolare il coinvolgimento di più parti, dev, ops e business, in più
momenti del ciclo complessivo. L’automazione naturalmente gioca un ruolo importante:
i tool DevOps, offerti sia dai main vendor IT sia da nuovi player specializzati in
quest’ambito, hanno il ruolo di automatizzare le attività per favorire il rilascio frequente
del software, la visibilità di tutti sulle varie fasi, la collaborazione tra i diversi team
coinvolti.
Da diverse indagini emerge poi che il Software Testing rappresenta ad oggi il principale
ostacolo per un delivery rapido in produzione. Sono ancora poche le aziende che hanno
alti livelli di test automation
3
.
2
Top 11 Things You Need to Know about DevOps, Gene Kim, http://itrevolution.com/
3
Devops and Continuous Delivery, Ten factors Shaping the Future of Application Delivery, EMA, 2014
CONTINUOUS DELIVERY
Continuous Delivery significa miglioramento continuo, significa testing ad ogni
modifica, significa costruire molti prototipi, e non andare avanti finché non si abbia
la certezza che ciò che abbiamo finora sviluppato è stato verificato a livello di
qualità e compatibilità, se non addirittura di user testing. Le attività prettamente
ingegneristiche coinvolte per assicurare uno sviluppo caratterizzato da continuous
delivery sono: controllo codice sorgente, versioning configuration, integrazione
continua, testing di unità e testing integrato, deployment automatizzato..
(CloudTalk.it, DevOps, la nuova buzzword dell’IT, cerchiamo di capire cos’è, http://bit.ly/1Jn1dZ7)

Da un punto di vista più generale, DevOps e CD (Continuous Delivery) abilitano cicli di
sviluppo e messa in produzione del software molto brevi, che sono proprio quanto ci si
aspetta in un mondo in cui player Internet e Cloud mostrano i livelli di performance
maggiori, come mostra la figura successiva.

In effetti, sia aziende tradizionali del mondo ICT, come software house, outsourcer e
system integrator, sia anche player di altri settori di mercato fortemente esposti alla
competizione, hanno oggi la necessità di trasformare parte del proprio business in servizi
Digital, erogati online e costantemente aggiornati. Per realizzare questa Digital
Transformation verso un mondo di servizi, al dipartimento IT è chiesto sempre di più uno
sforzo verso:
 Livelli più elevati di produttività
 Deployments rapidi, sfruttando il più possibile l’automazione di attività ripetitive
 Infrastrutture Agile, in grado di rispondere ad esigenze variabili.
Quali sono i principi generali da seguire per ottenere questa trasformazione culturale
verso DevOps e il Continuous Delivery? Si sta creando un’ampia letteratura su questo
tema e non mancano continui contributi. Riportiamo quelli di Gary Gruver e Tommy
Mouser in “Leading the Transformation: Applying Agile and DevOps Principles at Scale”
(IT Revolution, 2015).
1. Migliorare la qualità e la velocità dei feedback verso gli sviluppatori
Gli sviluppatori hanno bisogno di feedback tempestivi sulla qualità del software
sviluppato: solo in questo modo possono correggerlo rapidamente oltre che imparare a
non commettere più gli stessi errori. Il feedback inoltre non deve essere solo una
validazione del codice, ma deve fornire informazioni su come funziona il software in
produzione, nel momento in cui è utilizzato da un cliente. Il feedback dovrebbe quindi
arrivare da un test in un ambiente il più possibile simile a quello della produzione.
Questo è un punto di contatto importante tra dev e ops, perché ad esempio le operation
possono aggiungere propri criteri per le release all’ambiente di test. L’utilizzo di un tool
comune favorisce la collaborazione tra le 2 aree.
2. Riduzione del tempo e delle risorse necessarie per passare dallo sviluppo alla
produzione
Nelle grandi organizzazioni questo tipo di processo viene svolto tradizionalmente
impiegando molto tempo e molte persone: serve a individuare e correggere eventuali
errori nel codice. Per ridurre i tempi è necessario automatizzare parte dei collaudi di
regressione e implementare nuove funzioni di testing che gli sviluppatori devono
utilizzare molto più spesso nella fase di sviluppo. Inoltre gli sviluppatori devono essere
preparati per essere in grado di aggiungere nuove funzionalità e release branches senza
toccare o danneggiare il codice pre-esistente, in modo che la principale code branch
mantenga la propria release quality.
Essere in grado di fare un ciclo di full-regression testing completo su base quotidiana
riduce moltissimo i tempi del deployment. Inoltre permette di assegnare una priorità alle
feature più importanti (secondo quanto richiesto dal business) e rispettare tempistiche
molto stringenti per queste. Con un trunk principale del codice di elevata qualità e molto
stabile, gli sviluppatori devono prendere coscienza del fatto che eventuali
malfunzionamenti sono causa delle proprie aggiunte, e sono quindi motivati a produrre
giornalmente codice di più elevata qualità.

3. Rendere ripetibile l’intero processo di build, deploy, test
La ripetibilità del processo di sviluppo, test e deploy non è di solito assicurata, e questo
fatto comporta enormi inefficienze. Per piccole organizzazioni è più facile migliorare i
processi nella direzione di una maggiore ripetibilità. In grandi organizzazioni invece, con
molti team di ingegneri e svariate applicazioni che devono funzionare
contemporaneamente, diventa più difficile. Una deployment pipeline strutturata e
ripetibile è quindi molto importante e deve essere disegnata in modo da servire come
traccia operativa per tutto il processo.
4. Sviluppare un processo di deployment automatizzato che permette di
individuare in modo veloce qualsiasi problema legato al deployment o
all’ambiente di produzione
L’esperienza insegna che il processo di deployment cambia molto a seconda del singolo
caso. Se un’applicazione gira su molti server, il processo di debug può essere complicato
così come un collaudo per individuare difetti in un sistema complesso. Inoltre, problemi
durante i system test sono riconducibili sia al codice, sia al suo deployment: per questo
motivo è utile riuscire a identificare velocemente problematiche attribuibili soltanto agli
aspetti di deployment.
5. Rimuovere la duplicazione del lavoro che deriva dal supporto a molteplici
branch di codice simile
Per ridurre gli sprechi di tempo e ottimizzare il lavoro bisogna eliminare ogni
duplicazione. La proliferazione delle branch implica effort molto maggiori nel momento
in cui l’identificazione di un errore del codice obbliga a verifiche su tutte le branch
associate. Naturalmente ci sono molti motivi che giustificano lo sviluppo di branch
diverse, dalla necessità di rispondere a specifiche richieste dei clienti, a vari livelli di
stabilità associati ai diversi casi. Ciò nonostante i team di sviluppo possono riuscire a
lavorare su un unico trunk, se adottano sistemi di change management che lo
permettono, e questo in ultima analisi riduce molto le inefficienze legate alla
duplicazione del lavoro. E’ uno sforzo che in grandi organizzazioni richiede un po’ di
tempo ma dà benefici nel lungo termine.
A questi principi ne va aggiunto almeno uno, quello relativo alla documentazione e alla
consapevolezza generata da un monitoraggio di tutte le attività, come sottolinea Brett
Hofe in “L’arte della guerra nel mondo dei DevOps”
4
, da cui testualmente riportiamo:
(…) Fornire a ogni membro dell’esercito degli sviluppatori ordini chiari e concisi è
fondamentale se si vuole mantenere le priorità e raccogliere gli ordini in un
sistema di archiviazione, che consenta poi la tracciabilità completa dal
programmatore iniziale fino a chi ne fa richiesta. In questo modo chi comanda
potrà conoscere le proprie risorse e quantificare le aree di debolezza durante la
fase di sviluppo, oltre a capire dove indirizzare la responsabilità, la formazione
e/o fare correzioni. In questa fase è importante anche poter documentare,
quando si è a conoscenza, tutti gli obiettivi critici in termini di KPI e SLA come
parte integrante degli ordini specifici. (…)
4
Brett Hofe, Senior Solutions Architect-Dynatrace, LineaEDP, 8/4/2015, http://bit.ly/1M0Tr6q

Una volta eseguiti gli script di automazione dei test dell’unità, la ricchezza delle
informazioni raccolte da una tecnologia avanzata di gestione delle prestazioni
può diventare un patrimonio importante a cui attingere. Le tecnologie di
performance forniscono alert e sono in grado di eseguire operazioni
automatizzate, come emettere richieste di modifica che tornano alle truppe di
sviluppo quando ci sono criticità in termini di KPI o vengono violati gli SLA. (…)
Infine, giunge il momento di automatizzare le configurazioni infrastrutturali e i
deployment. Per garantire che ogni distribuzione possieda un setup ottimale per
il monitoraggio delle prestazioni avanzate, gli strumenti per la configurazione e il
release management devono certificare che tutte le impostazioni di
monitoraggio delle prestazioni corrette siano configurate all’interno di ogni
macchina target. In questo modo, una volta che il deployment di una fase viene
completato, tutte le operazioni che si verificano sul campo di battaglia possono
essere pienamente monitorate, offrendo una consapevolezza totale non solo
sulla loro struttura ma anche sull’impatto che i cambiamenti nella
configurazione possono comportare. Dopo aver preparato le unità ottimizzate e
aver reso più solido il nostro posizionamento siamo ora pronti ad affrontare
sfida della vera battaglia.
COME CAMBIA L’ORGANIZZAZIONE DEL LAVORO CON DEVOPS
Esiste oggi un professionista “DevOps”? Non è possibile al momento immaginarsi una
professionalità DevOps precisa, tante le competenze che sarebbero richieste. Invece si
parla già di team o “squadre DevOps”, gruppi di lavoro interfunzionali che abbracciano
più aspetti, sia dev sia ops, e portano avanti questa filosofia di lavoro basata su una
visione più ampia del flusso delle attività.
Come riportato nell’intervista fatta da The Innovation Group a Fausto Gentili, IT
Operation Manager di CRIF
5
, DevOps promuove un cambiamento di focalizzazione che
va a tutto vantaggio del business. Sistemisti e sviluppatori diventano maggiormente
orientati al business e hanno una visione end-to-end rivolta a comprendere qual è
l’utilizzo del software da parte del cliente finale, come richiesto da una cultura IT
orientata al service management.
Le Operation invece si sdoppiano: da una parte continuano ad essere importanti le
competenze tecnologiche su rete, storage, infrastrutture virtualizzate, dall’altra parte si
formano sistemisti che comprendono a fondo le logiche applicative dei servizi erogati,
affiancano i colleghi specialisti di infrastruttura e fungono da interfaccia verso le altre
aree dell’azienda. Si affermano quindi nell’IT professionalità in grado di vedere i servizi
nel loro complesso, interagendo con le componenti infrastrutturali, applicative e i
processi che governano il delivery delle soluzioni, siano esse in ASP o nelle varie
interpretazioni cloud.
5
“Con DevOps l’IT guarda oltre e riconosce sé stessa come elemento differenziante e competitivo”, 17 mag
2015, http://bit.ly/1QTDQsI

Nell’esperienza di CSI Piemonte (intervista di The Innovation Group a Fabrizio Barbero,
Direttore Gestione Piattaforme Trasversali e Integrazione di CSI Piemonte
6
) si parla di
una trasformazione forte soprattutto nel mondo del Development e Operation.
Secondo quando osservato in CSI, il cambiamento è passato anche attraverso la
ridefinizione delle figure professionali e degli skill di operation: da un lato sono rimaste e
si sono arricchite le professionalità specializzate sulla gestione delle infrastrutture del
data center, in particolare per governare un sistema cloud. Dall’altro lato, alcune risorse
sistemistiche hanno dovuto trasformarsi ed evolvere in un ruolo di partecipazione al
progetto di soluzioni finali all’interno del team di sviluppo (che è stato dotato di tutte le
professionalità necessarie alle realizzazione, delivery e operation del sistema).
L’esperienza di questi primi anni di utilizzo di DevOps a livello internazionale, come
descrive il DevOps Adoption Study (Rackspace, ottobre 2014), vede le organizzazioni
assegnare specifici ruoli DevOps, ad esempio DevOps Developer, DevOps System Admin,
DevOps Engineer, DevOps Specialist e Architect
7
. Queste professionalità hanno oggi
competenze più ampie rispetto al passato, come riportiamo testualmente in una
citazione.
“You could describe a DevOps sysadmin now as operations-as-a- service,
we do application management but also delivery, that continuous
delivery pipeline. If change rate is so high, some businesses are doing a
change every few seconds, you can’t inspect every change. Like a
production manager, you have to focus on the pipeline not the individual
thing. The role of operations is owning that Continuous Delivery pipeline.
Developers can focus on doing development, but with a better knowledge
that what they do is in service. Development will essentially expand
backwards, but the development pipeline will be owned by operations.”
Stephen Thair, DevOps Adoption Study, Rackspace, ottobre 2014.
Principale punto di attenzione deve essere quello di non creare – con il team DevOps –
un nuovo silos nell’organizzazione, ma di farlo interagire il più possibile con il resto delle
persone, ad esempio realizzando team cross function nell’organizzazione, in modo che le
nuove best practices sviluppate diventino gradualmente un bagaglio di conoscenza
comune nell’IT e nel business.
I BENEFICI OTTENUTI CON DEVOPS
Tra i benefici più spesso riscontrati presso chi ha scelto questa modalità operativa si ha:
 Minore time-to-market nei rilasci del software, che diventano più frequenti
 Cambiamento culturale verso una maggiore collaborazione ed efficienza operativa,
che si riflette in minore costo operativo per release software e la possibilità di
dedicare più tempo ad attività a valore aggiunto
6
“In CSI Piemonte DevOps rende interdipendenti sviluppo ed esercizio”, 29 mag 2015, http://bit.ly/1PWyfot
7
Devops Adoption Study, Rackspace, ottobre 2014

 Incremento della qualità del software (affidabilità più elevata in esecuzione, minor
numero di errori, maggiore successo dei change, ..)
 Possibilità di rendere disponibile il software per più piattaforme (come avviene per
quanto riguarda gli sviluppi di Mobile App)
 Maggiore visibilità sui processi IT e sui requisiti, quindi migliore controllo da parte
del CIO e del management.
I benefici di DevOps si estendono però ben oltre l’area IT e hanno impatto sulle
performance complessive del business. In particolare sono stati misurati:
 Migliore capacità dell’azienda di rispondere in modo tempestivo alle richieste del
mercato
 Maggiore numero di clienti che accede al software/servizi
 Soddisfazione maggiore nelle risorse
 Livelli di servizio (affidabilità, qualità del servizio) più elevati
 Maggiore Customer Satisfaction
 Migliori performance dell’IT che si riflettono rapidamente in un migliore andamento
del Business nel suo complesso, incrementi nelle vendite.
LE CRITICITÀ LEGATE ALLA TRASFORMAZIONE
Introdurre DevOps può incontrare dei freni, ed è bene tenerne conto da subito per
evitare che possano concorrere al fallimento di un progetto mal disegnato.
I principali sono da ricondurre alla resistenza al cambiamento messa in atto dalle
persone o alla mancanza di comprensione del valore di DevOps da parte di non
partecipanti al team iniziale o da parte del management. Anche la mancanza di
strumenti e competenze, oltre che di tempo e risorse da dedicare al tema, possono
rappresentare delle criticità. Inoltre potrebbe essere visto da alcuni come una “moda
passeggera” e non una modalità operativa destinata a perdurare.
A questi problemi si somma il fatto che in alcune organizzazioni di grande dimensione e
complessità, la trasformazione globale dei processi legati a sviluppo e produzione
potrebbe essere un obiettivo irraggiungibile.
In aziende tradizionali e di grande dimensione, per intraprendere questa trasformazione
può essere utile adottare un approccio con diverse velocità di esecuzione, o di “Bimodal
IT”. Secondo questo concetto, le organizzazioni, soprattutto quelle più ampie e
complesse, devono differenziare gli ambienti IT in modo che quelli tradizionali possano
continuare a far valere i propri principi di stabilità ed efficienza, mentre nel frattempo, in
parallelo, nuove entità IT possono crescere ed affermarsi, puntando ad altri valori, come
time-to-market, flessibilità, evoluzione rapida del software. In sostanza, questa “nuova
IT” è quella che adotta modelli operativi e strumenti nati con DevOps, e punta a
muoversi con la velocità delle società nate con il Cloud, come Google, Amazon, Netflix,
Facebook, Etsy.

LA ROADMAP PER IMPLEMENTARE DEVOPS
Molte aziende stanno cercando una strategia. Introducendo il 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 sono stimolati a scrivere codici di qualità superiore.
Come si fa, dunque, a introdurre il DevOps in azienda? Le esperienze riportate in
letteratura indicano alcune best practices.
1. Cercare la soluzione migliore per il proprio caso
Prima ancora di partire bisogna chiedersi perché potrebbe servire DevOps nella propria
organizzazione, quale specifico problema di business si vuole risolvere, o quale ambito IT
si vuole ottimizzare. Senza un motivo preciso è difficile ottenere un mandato per
procedere sulla strada di DevOps. Inoltre, bisogna considerare che non esiste un
implementazione uguale per tutti di DevOps, ma ogni singola realtà ne fa un utilizzo
molto personale e legato alla propria storia o cultura interna.
2. Partire in “piccolo” ma pensare in “grande”
Individuare un progetto che dovrà fungere da “catalizzatore”, ad esempio
un’applicazione da candidare a un processo di questo tipo. Individuare inoltre un team di
persone adatto ad affrontare il cambiamento, e creare con questo un Centro di

Eccellenza che non sia però separato dal resto dell’organizzazione. Misurare in tempi
rapidi i ritorni ottenuti e costruire con questi elementi iniziali un business case da
presentare al management. In prospettiva DevOps può portare a risultati importanti per
il business nel suo complesso, per cui conviene coinvolgere da subito nel progetto altre
funzioni aziendali, ad esempio la Direzione del Personale, l’area Organizzazione, l’area
Finance che può essere interessata a impatti sulle performance del business, il marketing
per quanto riguarda rilasci più rapidi del software.
3. Promuovere un cambio di cultura
Investire molto tempo sugli aspetti legati alla formazione delle persone, attraverso corsi
e seminari, puntando a creare uno spirito di collaborazione tra le persone delle diverse
funzioni, oltre che parlando e valutando esperienze fatte da terze parti.
4. Individuare e valutare strumenti DevOps
Per quanto le fondamenta di DevOps siano di natura metodologica, l’adozione richiede
strumenti a supporto delle nuove modalità operative, per cui è necessario individuare
tool di automazione confacenti con gli ambienti interni.
5. Misurare i risultati in ottica di miglioramento continuo
Il successo di DevOps dipende molto dall’aver attuato una misurazione continua da parte
del team di progetto sui risultati ottenuti (time-to-delivery, difettosità, performance, ..).
E’ importante inoltre definire dei KPI veramente risolutivi: devono essere agganciati il
più possibile al valore generato nel business, e devono seguire l’evoluzione molto rapida
dei modelli di business. E’ importante che DevOps non sia soltanto un tema tecnologico,
dei KPI guidati da performance tecnologiche potrebbero spingerlo in questa direzione.
Inoltre i KPI non sono immutabili: il mercato potrebbe un domani essere interessato a
servizi diversi. Bisogna quindi essere in grado di rispondere a nuove esigenze di
miglioramento nel tempo, e anche l’IT, che è fondamentale per supportare nuove
trasformazioni del business, deve essere il più possibile dinamica e flessibile nel tempo.
Per concludere, DevOps non è un prodotto o un tool ma piuttosto un approccio
operativo che trasforma quello che finora è stato il modo di organizzare le attività dello
sviluppo e deploy del software. All’inizio, per molte organizzazioni è un concetto un po’
vago, e questo può rendere difficile l’avvio di un progetto. Può essere utile ricordare
quindi che, per definire una strategia di successo con DevOps, bisogna basarla sui
seguenti 5 Pillar, o principi fondanti:
 CULTURA. Forte enfasi su collaborazione e comunicazione
 AUTOMAZIONE. Gli strumenti sono fondamentali per ridurre attività manuali
 LEAN IT. Principi Lean IT per abilitare una frequenza elevata dei cicli
 METRICHE. Misurazione, dati per rivedere i cicli, feedback continuativi
 CONDIVISIONE. Condivisione dell’esperienza per miglioramenti continui.
Bisogna essere in grado
di rispondere a nuove
esigenze di
miglioramento nel
tempo, e anche l’IT, che
è fondamentale per
supportare nuove
trasformazioni del
business, deve essere il
più possibile dinamica e
flessibile nel tempo

La proposta HP di soluzioni e servizi per DevOps
Le soluzioni di HP per DevOps, complete di tecnologia e servizi professionali a supporto,
sono pensate per abilitare una transizione graduale e non disruptive verso i nuovi
obiettivi di agilità, snellimento dei processi e visibilità oltre che controllo del rischio
promessi da DevOps. I team dello sviluppo e delle operation sono messi in condizione di
collaborare in modo efficiente per rilasciare applicazioni di qualità superiore in tempi
più rapidi. La proposta HP si suddivide in 4 stream che riprendono ambiti diversi, non
necessariamente successivi in ordine logico, ma compresenti nelle organizzazioni IT.
Continuous Integration & Testing: si tratta dell’ambito più vicino allo sviluppo.
L’obiettivo è offrire agli sviluppatori un ambiente condiviso di versioning e test, per
effettuare tutte le prove e le verifiche richieste sul codice, avere feedback veloci sulla
qualità del software realizzato, ingaggiare il business in fase di realizzazione e chiedere
le convalide necessarie per le fasi successive. La soluzione si basa su tecnologie HP
consolidate (come HP ALM e le suite di Test Automation) e di nuova generazione (come
HP Agile Manager e HP Lifecycle Virtualization Center).
Continuous Deployment & Delivery: questo ambito ha l’obiettivo di favorire la
collaborazione colmando il divario tra team di sviluppo e team operativi in modo da
raggiungere i risultati di business attesi. Partendo dalla Continuous Integration, la
Continuous Delivery aiuta ad automatizzare il processo di delivery, aggiungendo gli
elementi di deployment in ambienti di produzione e gestendo i requisiti di
configurazione. In questo modo si riducono tempi morti e si ottiene una più elevata
visibilità sulla pipeline complessiva. Le principali soluzioni HP per questo ambito sono:
HP Codar, HP Operation Orchestration.
Continuous Operation: le soluzioni di questo ambito hanno il compito di fornire
garanzie che l’intera architettura sia allineata e si possano evitare problemi nel
provisioning o test fuorvianti a causa di condizioni diverse negli ambienti di produzione.
HP mette a disposizione strumenti specifici per eseguire un Change Management per
DevOps, per ridurre le finestre di maintenance, prevenire downtime e incrementare le
perfomance complessive dell’infrastruttura. Le caratteristiche di elevata automazione di
questo ambito sono garantite dalle suite HP per Hybrid Cloud Management e Software
Defined Data Center.
Continuous Assessment: in parallelo ai precedenti ambiti, gli strumenti e le
competenze HP di Assessment tecnologico e monitoraggio continuativo, tramite la
raccolta di dati da operation, sviluppo, quality assurance, offrono visibilità upstream e
downstream; verificano tramite Big data analytics i livelli di performance dei servizi;
permettono di identificare ed isolare eventuali problemi delle applicazioni garantendo
una maggiore qualità dei processi realizzati in ottica IT Service Management,
minimizzando i rischi e ottimizzando l’utilizzo delle risorse disponibili. Le principali
tecnologie HP impiegate in questo ambito sono HP Application Lifecycle Intelligence e
HP Operations Analytics.
Per maggiori informazioni sulle soluzione HP per DevOps: Michele Piergiorgi,
michele.piergiorgi@hp.com.

A cura di:
Elena Vaciago, Research Manager, The Innovation Group
The Innovation Group (TIG) è una società di servizi di consulenza direzionale, advisory e ricerca
indipendente fondata da Roberto Masiero ed Ezio Viola, specializzata nella innovazione del
Business e dei processi aziendali attraverso l’utilizzo delle tecnologie digitali e delle nuove
tecnologie della conoscenza. Si rivolge ad Aziende ed Organizzazioni che desiderano sviluppare
strategie di crescita attraverso programmi, iniziative e progetti di innovazione del Business, di “go
to market”, di produzione e gestione integrata della conoscenza interna ed esterna dell’azienda
tramite le tecnologie ICT.
The Innovation Group è formato da un Team con esperienze consolidate, sia a livello locale sia
internazionale, si avvale del contributo di partnership strategiche con Aziende e Istituti
internazionali che garantiscono un forte e continuo sviluppo di ricerca e di conoscenza dei mercati,
delle tecnologie e delle migliori pratiche nei principali settori verticali. Alle Aziende e alle
Organizzazioni The Innovation Group si propone con un approccio pragmatico, volto ad affiancarle
ed accompagnarle nella fase di realizzazione di piani strategici, per valorizzare le risorse e le
capacità esistenti all’interno e prendere le decisioni più utili in tempi rapidi.
The Innovation Group si avvale di forti partnership internazionali per la ricerca e la conoscenza di
mercati, tecnologie e best practice.
Tutte le informazioni/i contenuti presenti sono di proprietà esclusiva di The Innovation Group (TIG) e sono da
riferirsi al momento della pubblicazione. Nessuna informazione o parte del report può essere copiata,
modificata, ripubblicata, caricata, trasmessa, postata o distribuita in alcuna forma senza un permesso scritto
da parte di TIG. L’uso non autorizzato delle informazioni / i contenuti della presente pubblicazione viola il
copyright e comporta penalità per chi lo commette.
Copyright © 2015 The Innovation Group.

TIGPaper_DevOps_170615 Final

More Related Content

What's hot (20)

Viewers also liked (18)

Similar to TIGPaper_DevOps_170615 Final (20)

More from Elena Vaciago (11)

TIGPaper_DevOps_170615 Final