DevOps: differenze tra le versioni

Versione delle 21:28, 16 nov 2019

Versione attuale delle 07:23, 13 nov 2023

(24 versioni intermedie di 19 utenti non mostrate)

Riga 1:

'''DevOps''' (dalla contrazione [[Lingua inglese|inglese]] di ''development'', "[[Sviluppo software|sviluppo]]", e ''[[operations]]'', qui simile a "messa in produzione" o "''[[deployment]]''") è una [[metodologia di sviluppo del software]] utilizzata in [[informatica]] che punta alla comunicazione, collaborazione e integrazione tra [[Sviluppatore software|sviluppatori]] e addetti alle ''[[operations]]'' della ''[[information technology]]'' (IT).<ref>{{Cita web

== Da dove deriva il termine DevOps ==

| url = http://www.rajiv.com/blog/2009/03/17/technology-department/

In [[informatica]], il termine '''DevOps''' deriva dalla contrazione [[Lingua inglese|inglese]] delle parole ''[[Sviluppo software|'''dev'''elopment]]'' e ''[[operations|'''op'''eration'''s''']]''.

| titolo = Organizing a Digital Technology Department of Medium Size in a Media Company

| data=17 marzo 2009

| lingua = inglese

| accesso = 15 luglio 2015

}}</ref>

DevOps vuole rispondere all'interdipendenza tra sviluppo software e IT operations, puntando ad aiutare un'organizzazione a sviluppare in modo più rapido ed efficiente prodotti e servizi [[software]].<ref>

{{Cita web

|url = http://somic.org/2010/03/02/the-rise-of-devops/

|autore = Dmitriy Samovskiy

|titolo = The Rise of DevOps

|opera = Fubaredness is contagious - preventing its spread in IT one post at a time (Dmitriy Samovskiy's Blog)

|data = 2 marzo 2010

|lingua = inglese

|accesso = 15 luglio 2015

|urlmorto = sì

|urlarchivio = https://web.archive.org/web/20110107130221/http://somic.org/2010/03/02/the-rise-of-devops/

|dataarchivio = 7 gennaio 2011

}}</ref><ref>{{Cita web

| url = http://dev2ops.org/blog/2010/2/22/what-is-devops.html

| titolo = What is DevOps?

| data = 23 febbraio 2010

| lingua = inglese

| accesso = 15 luglio 2015

| urlarchivio = https://web.archive.org/web/20120909013310/http://dev2ops.org/blog/2010/2/22/what-is-devops.html

| dataarchivio = 9 settembre 2012

| urlmorto = sì

}}</ref><ref name=mixing>

{{Cita web

|url = http://blogs.the451group.com/opensource/2010/03/03/devops-mixing-dev-ops-agile-cloud-open-source-and-business/

|titolo = DevOps mixing dev, ops, agile, cloud, open source and business

|data = 3 marzo 2010

|lingua = inglese

|accesso = 15 luglio 2015

|urlmorto = sì

|urlarchivio = https://web.archive.org/web/20150914010853/https://blogs.the451group.com/opensource/2010/03/03/devops-mixing-dev-ops-agile-cloud-open-source-and-business/

|dataarchivio = 14 settembre 2015

}}

</ref><ref>

{{Cita web

| url = http://www.cutter.com/promotions/itj1108/itj1108.pdf

| titolo = Devops: A Software Revolution in the Making?

| formato = PDF

| data = agosto 2011

| lingua = inglese

| accesso = 15 luglio 2015

}}

</ref>

==Descrizione==

Il termine venne utilizzato per la prima volta nel 2008 da Patrick Debois e Andrew Shafer<ref name=":0">

Le aziende che tipicamente potrebbero avere maggiori benefici da un orientamento DevOps sono quelle con rilasci di software frequenti. [[Flickr]] ha utilizzato il metodo DevOps per supportare la necessità di dieci rilasci al giorno;<ref>

{{Cita web|url=http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr|titolo=10+ Deploys Per Day: Dev and Ops Cooperation at Flickr|lingua=inglese|accesso=15 luglio 2015}}</ref> ma entrò davvero in uso comune dopo una presentazione al Velocity Conference del 2009 nella quale John Allspaw e Paul Hammond presentarono "+10 Deploy Software al Giorno: il Metodo di Cooperazione di Dev ed Ops a Flickr"

{{Cita web

<br />

| url = http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

| titolo = 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

| lingua = inglese

| accesso = 15 luglio 2015

}}</ref> tale ciclo di rilasci potrebbe essere più frequente in organizzazioni che producano applicazioni multi-focus o multi-funzione, spesso indicato come "''[[deployment]]'' continuo"<ref>{{Cita web

| url = http://www.cutter.com/promotions/itj1108/itj1108.pdf

| titolo = Why Enterprises Must Adopt Devops to Enable Continuous Delivery

| formato = PDF

| pagine = 6-12

| data = agosto 2011

| lingua = inglese

| accesso = 15 luglio 2015

}}

</ref> e associato spesso al metodo ''[[Lean Startup|lean startup]]''.<ref>

{{Cita web

| url = http://www.slideshare.net/pascallouis/applied-lean-startup-ideas-continuous-deployment-at-kaching

| titolo = Applied Lean Startup Ideas: Continuous Deployment at kaChing

}}

</ref>

Sull'argomento sono nati [[Gruppo di lavoro|gruppi di lavoro]], [[Ordine professionale|ordini professionali]] e [[blog]] sin dal 2009.<ref name=mixing/><ref name="devopsdaysghent">{{Cita web

|titolo=DevOps Days Ghent 2009

|url=http://www.devopsdays.org/events/2009-ghent/

| lingua = inglese

| accesso = 15 luglio 2015

|pubblicazione=DevopsDays}}

</ref><ref name="devopsdays">

{{Cita web

| url = http://www.devopsdays.org

| titolo = DevOps Days

| lingua = inglese

| accesso = 15 luglio 2015

}}

</ref><ref>{{Cita web

| url = http://dev2ops.org/blog/2010/4/26/devops-meetup-recap.html

| titolo = DevOps Meetup Recap

| nome = Damon

| cognome = Edwards

| data = 26 aprile 2010

| lingua = inglese

| accesso = 15 luglio 2015

| urlarchivio = https://web.archive.org/web/20120720183845/http://dev2ops.org/blog/2010/4/26/devops-meetup-recap.html

| dataarchivio = 20 luglio 2012

| urlmorto = sì

}}</ref>

Il metodo DevOps aiuta le aziende nella gestione dei rilasci, standardizzando gli ambienti di sviluppo. Le aziende con problemi di automazione dei rilasci solitamente hanno già un processo automatico in essere ma lo vorrebbero più flessibile e controllabile, senza per questo dover agire da [[Interfaccia a riga di comando|riga di comando]] per ottenere ciò. Idealmente tale automazione potrebbe essere utilizzata anche da risorse non operative (non appartenenti alle ''IT operations'') su ambienti non di produzione; in questo modo gli sviluppatori hanno a disposizione un maggiore controllo degli ambienti, dando all'infrastruttura una visione più incentrata sull'applicazione.

== Che cos'è DevOps, in breve ==

Devops è un metodo di rilascio e gestione, sia del software sia dell'infrastruttura (Hardware o Cloud) su cui il software viene sviluppato e messo in produzione.

L'integrazione DevOps ha come obiettivo il rilascio del prodotto, il [[collaudo del software]], l'evoluzione e il mantenimento (correzione di ''[[bug]]'' e ''[[Release (informatica)|release]]'' minori) in modo tale da aumentare affidabilità e sicurezza e rendere più veloci i cicli di sviluppo e rilascio. Molte delle idee che costituiscono DevOps provengono dalla gestione di sistemi aziendali e dalla [[Metodologia agile]].<ref name=AgileInf2010>

La filosofia DevOps si basa sul concetto delle '3 Ways' e sul creare una cultura di collaborazione e sperimentazione fra tutte le persone coinvolte nel rilascio di un determinato progetto software, sia personale tecnico sia non tecnico.

{{Cita web

| titolo=Agile Infrastructure

| url=http://www.infoq.com/presentations/agile-infrastructure

| editore=InfoQ

| lingua = inglese

| accesso = 15 luglio 2015

}}

</ref>

===Storia===

La Cultura DevOps nasce come risposta a un comune problema che si incontra in aziende medio-grandi che operano [[Information Technology|nell'IT]], dove sviluppatori e amministratori di sistemi si trovano spesso con obiettivi contrapposti.

Il termine "DevOps" è stato coniato da Patrick Debois<ref name=debois-devops>{{Cita web

| titolo=Patrick Debois on the State of DevOps

| url=http://www.infoq.com/interviews/debois-devops

| autore = Manuel Pais

| editore=InfoQ

| data = 6 aprile 2012

| lingua = inglese

| accesso = 15 luglio 2015

}}</ref> e reso popolare attraverso una serie di "DevOps Days" iniziati nel 2009 in Belgio.<ref name="devopsdaysghent"/>

Da allora si sono svolte conferenze "DevOps Days" in India, USA, [[Brasile]], [[Australia]], Germania, Svezia e Svizzera.<ref name="devopsdays"/>

[[File:Devops.svg|thumb|L'illustrazione mostra la DevOps come intersezione di Sviluppo (software engineering), technology operations e garanzia di qualità (Quality Assurance)]]

Gli uni, con lo scopo di inserire più [[funzionalità]] possibili nella prossima release, utilizzeranno sino all'ultimo giorno disponibile per scrivere codice.

Le metodologie di sviluppo (ad esempio la [[Metodologia agile]]) che vengono attuate nelle organizzazioni tradizionali mediante distinte divisioni tra IT operations e [[Garanzia di qualità|QA]] da un lato, sviluppo e rilascio dall'altro, sono prive di una profonda integrazione interdipartimentale. DevOps promuove un insieme di processi e metodi indirizzati alla comunicazione e collaborazione tra le divisioni.<ref>{{Cita web

|url = http://www.kartar.net/2010/02/what-devops-means-to-me/

|titolo = What DevOps means to me...

|nome = James

|cognome = Turnbull

|lingua = inglese

|accesso = 15 luglio 2015

|urlmorto = sì

|urlarchivio = https://web.archive.org/web/20101230030814/http://www.kartar.net/2010/02/what-devops-means-to-me/

|dataarchivio = 30 dicembre 2010

}}</ref>

L'adozione della metodologia DevOps è guidata da diversi fattori, come:

Gli altri, con lo scopo di mantenere l'[[uptime]] dei sistemi, che si ritroveranno con codice non propriamente testato e probabilmente contenente incongruenze da far funzionare in produzione.

# Utilizzo della metodologia agile e altre metodologie di [[Ciclo di vita del software|sviluppo del software]]

<br />

# Necessità di incrementare la frequenza dei rilasci in produzione

# Ampia disponibilità di un'infrastruttura virtualizzata<ref>{{Cita web

| url = http://www.it20.info/misc/virtualizationscomparison.htm

| titolo = Virtual Infrastructure products: features comparison

| opera = Welcome to IT 2.0: Next Generation IT infrastructures

| lingua = inglese

| accesso = 15 luglio 2015

| dataarchivio = 21 luglio 2011

| urlarchivio = https://web.archive.org/web/20110721214150/http://www.it20.info/misc/virtualizationscomparison.htm

| urlmorto = sì

}}</ref> e in [[Cloud computing|cloud]]

# Incremento nell'uso di [[data center]] automatizzati<ref>{{Cita web

|url = http://www.information-management.com/infodirect/20071026/10000120-1.html

|titolo = Bringing Order to Chaos through Data Center Automation

|nome = Jennifer

|cognome = Ellard

|opera = Information Management

|editore = SourceMedia

|lingua = inglese

|accesso = 15 luglio 2015

|urlmorto = sì

|urlarchivio = https://web.archive.org/web/20100611073000/http://www.information-management.com/infodirect/20071026/10000120-1.html

|dataarchivio = 11 giugno 2010

}}</ref> e strumenti di [[configuration management]] e [[Infrastructure as Code]]

La metodologia DevOps è spesso descritta come una relazione più collaborativa e produttiva tra i gruppi di sviluppo e quelli di operation. Ciò incrementa l'efficienza e riduce i rischi di frequenti modifiche in produzione. Per quantificare tale effetto si sta ragionando su alcuni possibili parametri.<ref>{{Cita web

== Descrizione ==

| url = http://www.zeroturnaround.com/blog/how-to-measure-the-effectiveness-of-implementing-devops

Premesso che tutte le aziende nell'IT possono trarre beneficio da una Cultura DevOps, passiamo a definire i tre principi di base a cui si fa spesso riferimento in letteratura DevOps come 'The Three Ways<ref name=":1">{{Cita libro|cognome=Kim, Gene. Phoenix project.|titolo=Summary of The phoenix project by Gene Kim, Kevin Behr, and George Spafford : a novel about IT, DevOps, and helping your business win.|url=http://worldcat.org/oclc/957127022|accesso=2019-11-15|OCLC=957127022|ISBN=9781945251078}}</ref>'.

| titolo = How to Measure the Effects of Development + Operations improvements, an OpenSpace conversation

| nome = David

| cognome = Booth

| lingua = inglese

| accesso = 15 luglio 2015

| urlarchivio = https://web.archive.org/web/20120723194935/http://zeroturnaround.com/blog/how-to-measure-the-effectiveness-of-implementing-devops/

| dataarchivio = 23 luglio 2012

| urlmorto = sì

}}</ref>

Il ruolo di un professionista DevOps ricorda molto la figura dell'ingegnere capo all'interno del cosiddetto "[[Toyota Production System]]".<ref>

'''The First Way:''' si parla di un flusso di lavoro che fa in un senso unico, in piccoli moduli e soprattutto nella maniera più automatizzata possibile; il flusso di codice va dallo Sviluppatore, al Tester, all'amministratore di sistema sino alla messa in produzione.

{{Cita libro

| titolo = The Toyota Way

| anno = 2004

| url = https://archive.org/details/toyotaway14manag00like

| editore = McGraw-Hill

| data = 17 dicembre 2003

| ed = 1

| id = ISBN 0-07-139231-9

}}

</ref> Tali figure sono responsabili del successo del progetto ma senza alcuna formale autorità sui diversi gruppi coinvolti. È loro richiesta conoscenza tecnica adeguata al fine di convincere i manager di quali siano le necessità e può essere di loro aiuto il sostegno da parte della dirigenza aziendale.

Invece, in molte organizzazioni, lo sviluppo del software e la gestione dei sistemi sono in divisioni differenti e poiché lo sviluppo è generalmente guidato dalle necessità dell'utente, per continue modifiche e conseguenti rilasci, i gruppi operativi sono concentrati sulla disponibilità e affidabilità dei servizi, nonché sulla gestione dei costi. Ciò produce un "gap" tra sviluppo e gestione dei servizi che rallenta il passaggio in produzione.

L'obiettivo è quello di ridurre il lavoro in moduli molto piccoli dove se un errore viene introdotto sia facilmente rintracciabile e non venga passato alle unità di lavoro seguenti.

'''The Second Way:''' si parla del concetto di feedback; questo flusso va in un senso unico opposto alla First Way, dove tutti gli errori e risultati dei test che vengono fatti sul codice, a qualsiasi livello prima di arrivare in produzione, vengono immediatamente segnalati all'unità di lavoro precedente.

Questo evita che gli errori, anche se minimi, vengano passati verso l'ambiente di produzione, e corretti, seguendo un modello agile di sviluppo.

'''The Third Way:''' si parla di creare una cultura che faccia della sperimentazione e del rischio calcolato uno stile di lavoro.

Uno stile di lavoro da cui si impara dai propri errori e si creano automazioni atte a riconoscere e riparare queste mancanze del software utilizzando sistemi terzi.

Si parla, in pratica di fare esattamente il contrario di quello che succede in un normale modello di sviluppo software e gestione sistemi: si cercano i punti deboli dell'infrastruttura o del codice e si causa il problema con l'obiettivo di trovare una soluzione che potrà gestire l'errore (gestire e non eliminare).

Utilizzando il sistema delle 3 Ways in azienda è possibile, con un ragionevole investimento iniziale, creare un team capace di rilasciare con cadenza regolare e automatizzare i processi in maniera tale che, anche se una versione contenente errori arrivasse in produzione, avremmo sui nostri sistemi un processo talmente standardizzato e testato che il roll-back a una precedente versione, o il rilascio di una hot-fix non rappresenterebbe una preoccupazione.

DevOps fa inoltre uso di tool software molto avanzati e di concetti innovativi che permettono alle aziende di salvaguardare tutta la produzione e installazione del software, documentando i processi mentre si scrive il codice per i processi stessi, rendendo tutte le operazioni che costituiscono una piattaforma software, ripetibili.

Concetti come Monitoring, Automazione delle installazioni, Configuration Management, Installazione e aggiornamento software vengono portati all'estremo, proprio per testare i limiti stessi delle piattaforme con l'obiettivo di migliorarle.

=== Impatto sui rilasci applicativi ===

In molte aziende che non fanno uso della Cultura DevOps i rilasci applicativi (release) sono eventi ad alto impatto e rischio, che coinvolgonocoinvolgendo più gruppi di lavoro;. conCon la metodologia DevOps questotale rischio si riduce, vediamoper i seguenti perchémotivi:

[[File:Agile-vs-iterative-flow.jpg|thumb|widthpx|L' illustrazione mostra l'effetto della metodologia agile nell'incrementare la frequenza degli eventi di rilascio, spesso misurati in giorni o settimane, in contrasto a grossi, rari rilasci, misurati in quadrimestri o anni, con le tradizionali metodologie di sviluppo.]]

; Numero ridotto di modifiche: L'adozione del modello agile o [[modello incrementale]], in contrasto con il tradizionale [[modello a cascata]] (Waterfall), comporta minori modifiche, anche se più frequenti, dovecon minore l'impatto di un errore può essere misurato a priori e facilmente individuatorischio.

; Accresciuto coordinamento dei rilasci: La presenza di una coordinazione del rilascio riduce le distanze tra sviluppo e gestione.

; Coordinamento nei rilasci:Non ci sono più "Silos" fra gli addetti ai lavori, tutti sono al corrente dei rilasci, dei task dei colleghi e dello stato della release software.

; Automazione: Una estremacompleta automazione assicura la facile ripetibilità dei rilasci e riduce gli errori umani nelle operazioni, dalle più triviali alle più complessenell'operazione.

=== Coordinatore del Rilascio (Release manager o Release Team)rilascio ===

Si tratta di un ruolo relativamente nuovo nelle aziende IT, il cui compito è di coordinare i rilasci in più ambienti pre-produzione (di sviluppotest). partendoLa dagli ambientinecessità di testtale perfigura arrivareviene agli ambienti di produzione.da:

* La necessità di ridurre il "gap" tra sviluppo e gestione

Questo ruolo è diventato necessario in aziende dove la Cultura DevOps ha attecchito particolarmente bene e dove i rilasci sono stati automatizzati a punto che ci si trova nella necessità di "rallentare" e registrare i rilasci software così che in presenza di un errore si possa tornare indietro e correggere il rilascio software colpevole del malfunzionamento (si parla ancora delle 3 Ways).

* Accresciuta complessità dell'infrastruttura, ad esempio applicazioni multipiattaforma

* Incremento della frequenza dei rilasci, ad esempio per via dell'utilizzo della metodologia agile

* Gruppi delocalizzati, come nel caso dell'utilizzo di risorse esterne o in sedi diverse

Il ruolo del coordinatore del rilascio (anche indicato come coordinatore d'integrazione) è simile a quello di un [[Controllore del traffico aereo|controllore di volo]] che deve coordinare in tempo reale attività di diversi gruppi per raggiungere un obiettivo (atterraggi e decolli in sicurezza) usando risorse condivise (spazio aereo, sentieri di volo, piste e terminali).

<br />

Tale coordinamento non va confuso con la gestione del rilascio, che è focalizzata sulla pianificazione delle modifiche al software in ottica di una loro applicazione direttamente sulla produzione, mentre il coordinatore del rilascio si occupa del lavoro sistematico e tecnico inerente alla creazione e rilascio del software nei vari ambienti.

== I falsi miti legati alla Cultura DevOps<ref name=":1" /> ==

==Note==

<references/>

== Voci correlate ==

<u>Il metodo DevOps rimpiazza il metodo Agile:</u> decisamente no, è infatti il contrario, DevOps cerca di rendere Agile cose che non lo sono mai state come infrastruttura, test e sicurezza delle piattaforme.

* [[Metodologia agile]]

* [[Lean innovation management]]

{{portale|informatica|linguistica}}

<u>DevOps significa NoOps:</u> a volte c'è chi pensa che DevOps possa significare l'eliminazione del reparto sistemi o test lasciando tutto sulle spalle degli sviluppatori. In pratica DevOps si basa sulle automazioni e le automazioni devono essere testate al pari del codice e del codice dell'infrastruttura.

Dedicando il solito numero di sviluppatori a task che prima erano di competenza di Tester e Sys-Admin si sta di fatto sovraccaricando la risorsa Sviluppatore che non sarà in grado di produrre codice alla stessa velocità.

<u>DevOps è solo per chi lavora con Software Open Source:</u> anche se agli albori questa tecnica di rilascio e gestione era praticata principalmente in ambito Linux e Open Source Software, oggi si contano molteplici organizzazioni che sviluppano in .Net, Sap o Cobol fra gli utilizzatiori di questa metodologia.

Si pensi che a oggi ci sono applicazioni di DevOps per apparati di rete e SMART appliance.

<u>DevOps è solo per gestire le infrastrutture Cloud(IaaC):</u> anche se in effetti uno dei vantaggi principali dei Tolls Devops è quello di trasformare l'infrastruttura in codice per poi lavorarla con i sistemi Agile, gli obiettivi del metodo vanno ben oltre quello che resta un semplice tool.

<u>DevOps è solo per Start-Up e aziende software:</u> un grande numero di compagnie a oggi fa uso di DevOps come strumento principale di release e gestione software, partendo dai pionieri Google, Amazon, Twitter ad arrivare a molte banche e assicurazioni a livello internazionale, per poi parlare di NETFLIX che ha fatto del metodo DevOps il cavallo di battaglia che ha portato la compagnia al successo.

<br />

==Note==

<references/>

[[Categoria:Information technology management]]

[[Categoria:Terminologia informatica]]