DevOps: differenze tra le versioni

Versione delle 16:06, 16 nov 2019

Versione delle 21:28, 16 nov 2019

Riga 1:

== Da dove deriva il termine DevOps ==

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

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

{{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 ande Paul Hammond presentarono "+10 Deploy Software al Giorno: il Metodo di Cooperazione di Dev ed Ops a Flickr"

<br />

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

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

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 chesia non tecnico.

La Cultura DevOps nasce come risposta ada 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.

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

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.

Riga 19:

== Descrizione ==

Premesso che tutte le aziende nell'IT possono trarre beneficio da una Cultura DevOps, passiamo a definire i 3tre 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>'.

'''The First Way:''' si parla di un flusso di lavoro che fa in un senso unico, in piccoli moduli e sopratuttosoprattutto nella maniera più automatizzata possibile; il flusso di codice va dallo Sviluppatore, al Tester, all'amministratore di sistema sino alla messa 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, docedove 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:''' Sisi 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 ede 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 ada una precedente versione, o il rilascio di una hot-fix non rappresenterebbe una preoccupazione.

DevOps fa inoltre uso di toolstool software molto avanzati e di concetti innovativi che permettono alle aziende di salvaguardare tutta la produzione ede 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 ede aggiornamento software vengono portati all'estremo, proprio per testare i limiti stessi delle piattaforme con l'obiettivo di migliorarle.

Utilizzando il sistema delle 3 Ways in azienda è possibile, con un ragionevole investimento iniziale, creare un team capace di rilasciare con cadenza regolare ed 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 ad una precedente versione, o il rilascio di una hot-fix non rappresenterebbe una preoccupazione.

DevOps fa inoltre uso di tools software molto avanzati e di concetti innovativi che permettono alle aziende di salvaguardare tutta la produzione ed 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 ed aggiornamento software vengono portati all'estremo, proprio per testare i limiti stessi delle piattaforme con l'obiettivo di migliorarle.

=== Impatto sui rilasci applicativi ===

In aziende che non fanno uso della Cultura DevOps i rilasci applicativi (releasesrelease) sono eventi ad alto impatto e rischio che coinvolgono più gruppi di lavoro; con la metodologia DevOps questo rischio si riduce, vediamo perché:

[[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, dove l'impatto di un errore può essere misurato a priori e facilmente individuato.

; 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 estrema automazione assicura la facile ripetibilità dei rilasci e riduce gli errori umani nelle operazioni, dalle più triviali alle più complesse.

=== Coordinatore del Rilascio (Release manager oro releaseRelease Team) ===

Si tratta di un ruolo relativamente nuovo nelle aziende IT, il cui compito è di coordinare i rilasci in più ambienti di sviluppo partendo dagli ambienti di test per arrivare agli ambienti di produzione.

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 (Sisi parla ancora delle 3 Ways).

<br />

Line 57 ⟶ 55:

<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, teststest e sicurezza delle piattaforme.

<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 TestersTester e Sys-AdminsAdmin 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 ede Open Source Software, oggi si contano molteplici organizzazioni che sviluppano in .Net, Sap o Cobol fra gli utilizzatiori di questa metodologia.

Si pensi che ada oggi ci sono applicazioni di DevOps per apparati di rete e SMART appliancesappliance.

<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 ede aziende software:</u> un grande numero di compagnie ada oggi fa uso di DevOps come strumento principale di release e gestione software, partendo dai pionieri Google, Amazon, Twitter ad arrivare a molte Banchebanche ede Assicurazioniassicurazioni 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==