Qual è la differenza tra DevOps e automazione?

Vedo che ogni volta che qualcuno fa DevOps, si tratta principalmente di automatizzare cose come la distribuzione, ecc.

Ma dove finisce l'automazione e inizia DevOps?

Una grande parte di DevOps sta rendendo possibile il rilascio molto spesso. Viene fornito con build automatizzata, test automatizzati, ecc. Puoi dire che per raggiungere i suoi obiettivi, DevOps deve usare l'automazione per essere efficiente.

Ecco come sono correlati DevOps e automazione. DevOps non è solo automazione, c'è di più. Al contrario, l'automazione non è utilizzata esclusivamente da "DevOps people". Molta automazione stava avvenendo nell'IT prima che arrivasse DevOps.

Si prega di non considerare il diagramma sopra per rappresentare tutto ciò che è DevOps, o tutto ciò è automazione. Serve ad aiutare il lettore a immaginare come siano collegati i due concetti.

L'automazione è un attributo chiave di DevOps, ma non è la storia completa. La domanda è un po 'come "Qual è la differenza tra time-boxing e Scrum?".

Sentirai DevOps chiamato una 'cultura', un 'movimento', una 'metodologia' e tutti i tipi di cose che non lo racchiuderanno abbastanza bene per poterlo capire, anche se quelle descrizioni sono accurate. In breve, DevOps riguarda la confluenza di metodologie, automazione e virtualizzazione Agile che consentono un nuovo ciclo di feedback nella gestione / controllo / direzione di un progetto software.

Con un'automazione aggressiva, le cose che impiegano molto tempo e sono soggette a errori umani ora accadono rapidamente e senza incidenti. Di conseguenza, tendiamo a farli più spesso. Un esempio principale di ciò è una "distribuzione in produzione". Abbiamo usato per salvare grandi quantità di lavoro e distribuirli fuori orario nel caso in cui "qualcosa fosse andato storto". Ma ora possiamo implementare le modifiche più volte al giorno, in modo da ridurre drasticamente le possibilità di "qualcosa che non va" e in modo che l'impatto di qualcosa che non va sia molto più piccolo quando si verifica.

Una volta che abbiamo messo in atto questo processo ripetibile, iniziamo a vederlo come una 'pipeline'. I requisiti entrano, esce il codice distribuito nella produzione. Automatizziamo tutto lungo questa pipeline: test, documentazione, fusioni, implementazioni e altri test, e così via ... Poiché le persone si concentrano sull'automazione, non vedono la "mentalità della pipeline" che l'ha guidata. Questa è la metodologia di gestione - l'attenzione prestata alla pipeline - che rende DevOps più che automazione.

Una volta implementata tale automazione, iniziano i circuiti di feedback. Iniziamo a misurare cose come il tempo di ciclo in modo da poter capire cose che in precedenza avevamo provato a indovinare con le stime. Le cose sull'architettura che rendono difficile l'automazione / la consegna continua tendono a essere sostituite con modelli architettonici alternativi che rendono più semplice l'automazione / la consegna continua (diversi esempi di questo sono documentati nel libro "Database evolutivi". "Le implementazioni Green / Blue" sono un'altra ).

Nota che sono stato in grado di fornire questa descrizione senza parlare di Jenkins, Check, Puppet, Ansible, Vagrant, AWS o di qualsiasi altro strumento che la supporti. Questo è ciò che intendiamo con parole d'ordine di livello più grande come "metodologia". Alla fine, qualsiasi set di strumenti può essere sostituito ... Ciò che ci rimane sono i principi di gestione fondamentali abilitati dall'automazione e l'attenzione sulla pipeline.

DevOps è davvero un cambiamento culturale - ha lo scopo di abbattere le tradizionali barriere tra operazioni e sviluppo (e davvero anche con QA e il resto del business!). L'idea è che invece di disporre di "silos" dipartimentali, è possibile lavorare direttamente con altri team per svolgere le attività in modo più rapido ed efficiente.

Si tratta di rimuovere i vincoli e semplificare i processi. L'automazione arriva in questo ambito perché avere processi ripetibili aiuta a rimuovere i vincoli. Ad esempio: se qualcuno delle operazioni operative deve eseguire un processo di rilascio manuale per distribuire il codice in un ambiente, ci sono un paio di cose che possono ostacolare: una è che ci deve essere qualcuno nelle operazioni libere per eseguire la distribuzione, e due, c'è meno fiducia nel processo di rilascio perché il lavoro manuale è soggetto a errori.

DevOps include l'automazione ma questa è solo una parte di essa. DevOps è un cambiamento culturale per abbattere i silos tra le diverse parti dell'organizzazione per fornire un flusso di valore completo. Fornire una cultura in cui business, sviluppo, controllo qualità, infrastruttura, sicurezza, operazioni, ecc. Lavorino tutti insieme per fornire valore a chi è sempre l'utente finale. DevOps non è uno strumento, non puoi acquistarlo, devi cambiare la tua cultura.

L'automazione è una parte fondamentale di DevOps in quanto consente la velocità di consegna con qualità. L'automazione per il processo di distribuzione è una delle aree su cui molte persone si concentrano per prime in quanto è uno dei modi migliori per guadagnare valore rapidamente e fornisce un elevato ritorno sugli investimenti, non solo riducendo i tempi di distribuzione, ma anche standardizzando il processo e rimuovendo errori.

Vorrei aggiungere i miei 2 centesimi:
1) Automazione :
     qualcosa a cui oggi dobbiamo muoverci. È diventato più una necessità in cui il modo preferito sarebbe quello di automatizzare i pezzi, se non l'intero processo. Questo approccio offre agli utenti (sviluppatori) la flessibilità di utilizzare un passaggio fisso e di essere in grado di personalizzare secondo necessità.
     Il vantaggio di questo approccio è che possiamo automatizzare le parti che desideriamo mentre il singolo processo può essere collegato dallo sviluppatore. Più i passaggi di automazione sono granularizzati, migliore è il controllo che hanno.
     Inoltre, ci sono molti strumenti per l'automazione in spazi come l'automazione robotica, l'automazione SOP (per l'industria della manutenzione), l'automazione dei report (come Splunk), ecc.
2) DevOps:
     Data la qualità della consegna e la tempestività che ci si aspetta dal mondo attuale, è necessario estendere l'automazione del processo di consegna del software. Per consentire ciò e fornire valore al cliente nel modo più rapido possibile, DevOps fa ampio affidamento sugli strumenti di automazione.
     Il vantaggio di questo approccio è che, i singoli passaggi possono essere automatizzati per garantire coerenza all'interno dell'azienda, mentre l'orchestrazione generale può essere modificata per adattarsi al processo necessario per quel progetto.
     I singoli strumenti di automazione (in un certo senso) come Chef per la distribuzione, Docker tramite Dockerfile, Maven per la costruzione, ecc. Possono essere collegati probabilmente tramite Jenkins per fornire la soluzione richiesta e allo stesso tempo ridurre i tempi necessari per l'implementazione o l'utilizzo .
Spero che questo aiuti ad aggiungere valore al processo di pensiero che potresti già avere.

Modifica: ho dimenticato di aggiungere che avevo parlato del processo e degli strumenti - 2 dei 3 aspetti in DevOps. Come menzionato dagli altri, il terzo aspetto e altrettanto importante sono le persone. Una delle maggiori differenze che presumo tra questo e l'automazione sarebbe che le persone sono più inclini ad assorbire l'automazione più frequentemente di quanto resisterebbero a DevOps. Ritengo che ciò sia dovuto alla natura stessa di DevOps, in quanto l'automazione è solitamente associata a rendere le cose più facili per loro, mentre ritengono che DevOps stia cambiando il modo in cui si sentono a proprio agio.

Il movimento DevOps consiste in quattro aree principali abbreviate come CAM :

1. Cultura
2. Automazione
3. misurazione
4. Condivisione

Ecco il post di definizione originale del 2010.

In ogni area ci sono alcuni strumenti, processi e pratiche che sono generalmente accettati, sebbene l'argomento non sia ben definito per le migliori pratiche, nella maggior parte dei casi ci sono alcune buone pratiche da seguire.

L'automazione di per sé è un argomento un po 'più ampio, ma nel contesto di DevOps è solo un sottoinsieme di ciò che viene trattato. Prendi nota che guidiamo con la cultura, anche se molti professionisti DevOps sul campo spesso la trascurano a loro rischio e pericolo e passano direttamente all'automazione.

Automazione e DevOps non sono correlati. DevOps è più simile all'ingegneria combinata in cui gli sviluppatori di un sito o servizio sono tutti gli operatori di quel sito o servizio. Perché questo romanzo? Nella mia esperienza, la prima cosa che ha fatto il team Ops quando è successo qualcosa di più eccitante di un blip di rete è stato chiamare il team Dev. Perché l'hanno fatto? Perché tutto il team Ops ha fatto è stato monitorare e tenere un elenco di numeri di telefono di sviluppo da chiamare.

Si noti che non ho detto nulla sull'automazione.

L'automazione consiste nel ripetere il successo. Se eseguo i passaggi a, bec e il processo X funziona sempre, i passaggi a, bec sono buoni candidati per l'automazione. Quindi posso usare il tempo per quello che era un processo manuale per fare cose che mi fanno guadagnare di più. L'automazione ha successo quando è semplice. La distribuzione di nuove versioni, l'esecuzione di test di integrazione, il serraggio di un dado su un bullone, il backup dei dati, il bilanciamento dei crediti rispetto ai debiti, ecc. Sono tutti ottimi candidati per l'automazione perché i passaggi vengono ripetuti da una persona o un robot.

Nota : la novità è che gli sviluppatori sono anche gli operatori. Non esiste un altro gruppo. La cooperazione nel mio caso era rara. Se nella Guida alla risoluzione dei problemi (alias TSG) non c'era nulla, allora ti era garantita una telefonata. Nella mia esperienza, Ops è stata la prima chiamata in caso di terne. I problemi tra i servizi erano fuori dalla loro timoneria.