Devops

Da Wikipedia, l'enciclopedia libera.

DevOps (da development + operations) è una metodologia di sviluppo del software che punta alla comunicazione, collaborazione e integrazione tra sviluppatori e addetti alle operations dell'information technology (IT).[1] DevOps vuole rispondere all'interdipendenza tra sviluppo software e IT operations. Punta ad aiutare un'organizzazione a sviluppare in modo più rapido ed efficiente prodotti e servizi software.[2][3][4][5][6]

Le aziende che tipicamente potrebbero avere maggiori benefici da un orientamento DevOps sono quelle con rilasci di software frequenti. Flickr ha utilizzato la metodologia DevOps per supportare la necessità di dieci rilasci al giorno;[7] tale ciclo di rilasci potrebbe essere più frequente in organizzazioni che producano applicazioni multi-focus o multi-funzione, spesso indicato come deployment continuo[8][9] e associato spesso alla metodologia Lean Startup.[10] Sull'argomento sono nati gruppi di lavoro, ordini professionali e blog sin dal 2009.[5][11][12]

La metodologia 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 riga di comando per ottenere ciò. Idealmente tale automazione potrebbe essere utilizzata anche da risorse non operative (non appartenenti all'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.

L'integrazione DevOps ha come obiettivo il rilascio del prodotto, il collaudo del software, l'evoluzione e il mantenimento (bug fixing e "minor release") 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.[13]

Storia[modifica | modifica wikitesto]

Il termine "devops" è stato coniato da Patrick Debois[14] e reso popolare attraverso una serie di "DevOps Days" iniziati nel 2009 in Belgio.[15] Da allora si sono svolte conferenze "DevOps Days" in India, USA, Brasile, Australia, Germania e Svezia.[16]

L'illustrazione mostra la DevOps come intersezione di Sviluppo (software engineering), technology operations e garanzia di qualità (Quality Assurance)

Le metodologie di sviluppo (ad esempio la Metodologia agile) che vengono attuate nelle organizzazioni tradizionali mediante distinte divisioni tra IT operations e 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.[17]

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

  1. Utilizzo della metodologia agile e altre metodologie di sviluppo del software
  2. Necessità di incrementare la frequenza dei rilasci in produzione
  3. Ampia disponibilità di un'infrastruttura virtualizzata[18] e in cloud
  4. Incremento nell'uso di data center automatizzati[19] e strumenti di configuration management

La metodologia DevOps è spesso descritta come un 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[20].

Il ruolo di un professionista DevOps ricorda molto la figura dell'ingegnere capo all'interno del cosiddetto "Toyota Production System".[21] Tali figure sono responsibili 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.

Impatto sui rilasci applicativi[modifica | modifica wikitesto]

In molte aziende i rilasci applicativi sono eventi ad alto impatto e rischio, coinvolgendo più gruppi di lavoro. Con la metodologia DevOps tale rischio si riduce per i seguenti motivi:

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, comporta minori modifiche, anche se più frequenti, con minore impatto e rischio.
Accresciuto coordinamento dei rilasci
La presenza di una coordinazione del rilascio riduce le distanze tra sviluppo e gestione.
Automazione
Una completa automazione assicura la facile ripetibilità dei rilasci e riduce gli errori nell'operazione.

Coordinatore del Rilascio[modifica | modifica wikitesto]

Si tratta di un ruolo relativamente nuovo nelle aziende IT, il cui compito è di coordinare i rilasci in ambienti pre-produzione (di test). La necessità di tale figura viene da:

  • La necessità di ridurre il "gap" tra sviluppo e gestione
  • 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 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).

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.

Note[modifica | modifica wikitesto]

  1. ^ Organizing a Digital Technology Department of Medium Size in a Media Company, 17 marzo 2009.
  2. ^ The Rise of DevOps in Fubaredness Is Contagious, 2 marzo 2010.
  3. ^ What is DevOps?.
  4. ^ Steve Ballmer gets Cloud.
  5. ^ a b DevOps mixing dev, ops, agile, cloud, open source and business.
  6. ^ Devops: A Software Revolution in the Making?.
  7. ^ 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr.
  8. ^ SAM SIG: Applied Lean Startup Ideas: Continuous Deployment at kaChing.
  9. ^ Why Enterprises Must Adopt Devops to Enable Continuous Delivery.
  10. ^ Applied Lean Startup Ideas: Continuous Deployment at kaChing.
  11. ^ DevOps Days 2009 Conference.
  12. ^ Damon Edwards, DevOps Meetup Recap.
  13. ^ Agile Infrastructure, InfoQ. URL consultato il 31 marzo 2011.
  14. ^ Intervista su InfoQ. URL consultato il 21 giugno 2013.
  15. ^ DevOps Days Ghent 2009 in DevopsDays. URL consultato il 31 marzo 2011.
  16. ^ DevOps Days in DevOps Days, 31 marzo 2011.
  17. ^ James Turnbull, What DevOps means to me....
  18. ^ Virtual Infrastructure products: features comparison in Welcome to IT 2.0: Next Generation IT infrastructures.
  19. ^ Jennifer Ellard, Bringing Order to Chaos through Data Center Automation in Information Management, SourceMedia.
  20. ^ David Booth, How to Measure the Effects of Development + Operations improvements, an OpenSpace conversation.
  21. ^ The Toyota Way, 1ª ed., McGraw-Hill, 17 dicembre 2003, ISBN 0-07-139231-9.