Fondamenti e concetti di DevOps

In questo post tratteremo le basi, i concetti e le pratiche essenziali per chiunque lavori in un ambiente DevOps.

Tratteremo quanto segue:

• Cultura - La cultura della collaborazione tra Dev e Ops
• Pratiche - Le pratiche che supportano gli obiettivi della cultura DevOps
• Utensili - Gli strumenti che aiutano a implementare le pratiche DevOps
• Nube - La stretta relazione tra DevOps e il cloud

Cos'è DevOps

DevOps = Dev (sviluppo) + Ops (operazioni)

Questa definizione di Wikipedia è un buon punto di partenza:

'DevOps è una cultura e pratica dell'ingegneria del software che mira a unificare lo sviluppo del software (Dev) e il funzionamento del software (Ops) ... DevOps mira a cicli di sviluppo più brevi, maggiore frequenza di distribuzione, versioni più affidabili, in stretto allineamento con gli obiettivi aziendali.'

DevOps Is

• DevOps è innanzitutto una cultura della collaborazione tra sviluppatori e persone operative
• Questa cultura ha dato origine a una serie di pratiche
• DevOps è un modo di lavorare
• DevOps è un movimento, da parte di professionisti, per professionisti

DevOps non lo è

• DevOps NON è un insieme di strumenti, ma gli strumenti sono essenziali per il successo in DevOps
• DevOps NON è uno standard
• DevOps NON è un prodotto
• DevOps NON è un titolo professionale

Cultura DevOps

La cultura DevOps riguarda collaborazione tra Dev e Ops. Tradizionalmente, i due lavoravano separatamente e avevano diverso e opporsi obiettivi.

Nella cultura DevOps, Dev e Ops lavorano insieme e condividono il stesso obiettivo . Questo significa che gli sviluppatori si preoccupano della stabilità e della velocità, e gli operatori si preoccupano della velocità e della stabilità.

I ruoli tradizionali degli sviluppatori e degli ingegneri operativi diventano confusi con DevOps.

Invece di 'lanciare codice oltre il muro', sviluppatori e op lavorano insieme per creare e utilizzare strumenti e processi che supportano velocità e stabilità.

Con DevOps:

• Dev e Ops giocano nella stessa squadra
• 
  

  Dev e Ops condividono gli stessi obiettivi

  
  
  
  
  • Time-to-market (TTM) veloce
  
  
  • Pochi fallimenti di produzione
  
  
  • Ripristino immediato dai guasti
  
  

Silos tradizionali

Cosa c'era di sbagliato nei silos tradizionali?

Sotto i silos tradizionali:

• Gli sviluppatori scrivono del codice
• 'Gettalo oltre il muro' per QA
• Il codice rimbalza avanti e indietro tra lo sviluppo e il controllo qualità quando il controllo qualità rileva i problemi e gli sviluppatori li risolvono
• Finalmente è pronto per la produzione

• QA / Dev 'lancia il codice oltre il muro' in Operations
• Se c'è un problema, Ops lo rigetta oltre il muro a Dev
• Il dominio di ogni gruppo è una 'scatola nera' per gli altri gruppi
• Ops direbbe: “I nostri sistemi vanno bene; è il tuo codice! '
• Dev direbbe: 'Ma il codice funziona sulla mia macchina!'

Questo modo di lavorare porta a puntare molto il dito: le operazioni sono una scatola nera, gli sviluppatori non si fidano davvero di loro e le operazioni non si fidano davvero degli sviluppatori.

Dev e Ops hanno priorità diverse: Ops considera gli sviluppatori come una stabilità che infrange e gli sviluppatori considerano le operazioni come un ostacolo alla distribuzione del proprio codice.

Anche se VOGLIONO lavorare insieme, lo sviluppo viene misurato fornendo funzionalità, il che significa distribuire le modifiche e le operazioni vengono misurate in base al tempo di attività, ma le modifiche sono negative per la stabilità.

Aspetti negativi dei silos tradizionali

• Le 'scatole nere' portano al dito puntato
• Un processo lungo significa un lento time-to-market
• La mancanza di automazione significa che cose come build e distribuzioni sono incoerenti
• Ci vuole molto tempo per identificare e risolvere i problemi

Unione di sviluppo e operazioni (DevOps)

In che modo DevOps risolve i problemi dei silos tradizionali?

Sotto il modello DevOps:

• Gli sviluppatori scrivono il codice
• Il commit del codice attiva build, integrazione e test automatizzati
• QA può metterci le mani su quasi immediatamente
• Una volta pronto, avvia una distribuzione automatizzata in produzione

• Poiché tutto è automatizzato, è molto più facile da distribuire mantenendo le cose stabili
• Le distribuzioni possono verificarsi molto più frequentemente, portando le funzionalità nelle mani dei clienti più rapidamente
• Se l'ultima distribuzione interrompe qualcosa in produzione, il monitoraggio automatizzato avvisa immediatamente il team
• Il team esegue un rollback distribuendo la versione funzionante precedente, risolvendo rapidamente il problema
• Un'ora dopo, il team di sviluppo è in grado di distribuire una versione fissa del nuovo codice

Dev e Ops hanno collaborato per dare priorità sia alla velocità di consegna che alla stabilità.

L'automazione ha portato alla coerenza: la creazione, il test e la distribuzione sono avvenuti allo stesso modo ogni volta, molto più rapidamente e più spesso

Un buon monitoraggio, oltre al rapido processo di distribuzione, ha garantito che i problemi potessero essere risolti anche prima che gli utenti li notassero. Anche se una modifica del codice ha causato un problema, gli utenti hanno riscontrato tempi di inattività minimi o nulli.

Vantaggi di DevOps

• I team tecnologici tendono ad essere più contenti di fare DevOps piuttosto che essere in silos tradizionali
• Più tempo per innovare e meno tempo per spegnere gli incendi
• Devs e Ops condividono entrambi lo stesso obiettivo che è la velocità di consegna e il sistema stabile.
• Il modo di lavorare DevOps offre ai clienti le funzionalità che desiderano in modo rapido e affidabile.