DevOps significa che gli sviluppatori ora si assumono la responsabilità dell'infrastruttura e del rilascio, ma quali sono i fattori che stanno alla base di questo cambiamento?

Il motivo principale è il cloud.

Un tempo il codice veniva spedito su dischetto e poi su CD, quindi veniva distribuito su un server e poi distribuito su due server (per la resilienza) ... E tutta quella distribuzione poteva essere fatto manualmente da un essere umano, quindi gli umani sono stati addestrati a farlo.

Oggi il tuo codice spesso va a decine o centinaia di server. Il provisioning, la configurazione e la distribuzione su quei server non possono essere realisticamente eseguiti manualmente da un essere umano. Hai bisogno che i tuoi amministratori di sistema conoscano abbastanza script per automatizzare tale processo, dal momento che ora stai utilizzando Chef oi suoi parenti. Ma francamente, non c'erano abbastanza amministratori sys che potessero farlo. Così gli sviluppatori sono stati tirati dentro per riprendere il gioco.

E sì, aggiungere più abilità alle crescenti esigenze degli sviluppatori sta naturalmente riducendo la loro competenza altrove. L'idea è quella di consentire l'intuizione dello sviluppo del processo di creazione / rilascio, di anticipare meglio i problemi o di avere l'autonomia per migliorarlo. L'idea è che la qualità di ogni cosa aumenta da quando le vincite del rilascio superano le perdite di scrittura del codice.

Sono scettico sul fatto che il trade off valga la pena tanto quanto le persone lo dimostrano.

Ci sono molti motivi diversi per cui varie organizzazioni possono passare a DevOps.
Proverò ad elencare quelli che vengono fuori spesso.

Riduci il tempo di cambiare ciclo
C'è spesso molto tempo tra fare una richiesta di cambiamento e in realtà viene distribuito e utilizzato nell'organizzazione. Prima è pianificato in uno dei cicli di sviluppo dagli sviluppatori e dopo che è stato consegnato è pianificato in uno dei cicli di rilascio delle operazioni. Entrambi i cicli includono test e in caso di problemi rilevati, entrambi i cicli vengono ripristinati. Integrando i dipartimenti di sviluppo e operativi, possiamo semplificare entrambi i processi.

Problemi software vs hardware
Ricorda il cartone animato Bugs Bunny dove Bugs e Daffy stanno discutendo se è stagione di anatra o stagione dei conigli? Ora immaginiamo di averlo fatto con sviluppatori e operazioni in cui gli sviluppatori sostengono che si tratta di un problema hardware e le operazioni sostengono che si tratta di un problema software. Per l'utente finale questa è una distinzione senza differenze. Vogliono solo riparato.
Portando insieme gli sviluppatori e le operazioni, dovranno risolvere i problemi. E potrebbe rivelarsi un problema di software e hardware.

Noi contro loro
In molte aziende la distanza tra tester e sviluppatori era in crescita perché erano reparti separati e il ciclo di sviluppo stava diventando sempre più formalizzato e standardizzato.
Con l'avvento di Agile, sviluppatori e tester hanno lavorato a stretto contatto e abbiamo iniziato a vedere il punto di vista reciproco sul ciclo di sviluppo e forse addirittura a rispettarlo.
Qualcosa di simile deve accadere tra gli sviluppatori e le operazioni, perché quando entrambi i campi maturano e i processi si formalizzano e standardizzano ulteriormente, la distanza tra questi reparti è in aumento. Quindi uno dei problemi con il modello tradizionale è che sembra "noi" contro "loro" per gli sviluppatori e le operazioni simili. Entrambi non comprendono completamente la difficoltà delle responsabilità dell'altro.

Aspettative / Upsides
Con DevOps entrambe le specialità impareranno alcune delle abilità tradizionalmente eseguite dall'altro. Nessuno si aspetta che un amministratore di sistema diventi un ingegnere del software o uno sviluppatore per diventare un ingegnere di rete, ma entrambi dovrebbero assumersi alcune delle responsabilità dell'altro. Ciò significa che quando hai davvero bisogno di alcune mani in più, sono lì.

E ci sono alcuni aspetti positivi per gli sviluppatori: ora hai più controllo sugli ambienti di test, troverai più facile distribuire il software agli utenti e avere più persone della tua organizzazione con cui condividere il tuo amore per il mestiere.

Scrivere un codice di qualità non è sufficiente. Sei parte del problema o parte della soluzione.

Per molti programmatori, stai scrivendo software che viene pagato da qualche utente finale. Scrivere un codice di qualità è una buona cosa, ma è anche qualcosa che i clienti / manager pensano che tu debba sempre fare e fare in fretta. È come dire che un falegname taglia le tavole con precisione, ma in realtà stai costruendo qualcosa che qualcuno vuole pagare?

DevOps offre agli sviluppatori un maggiore controllo e si spera che il loro codice sia in linea con il risultato finale. Chi è il più adatto per automatizzare il processo operativo? La soddisfazione dell'utente finale è il principale strumento di misura. Non solo devi scrivere codice di qualità, ma deve soddisfare il cliente. Scusa, ma nessuno sta tornando a utilizzare le righe di codice. A loro non importa se hai costruito il tuo framework ORM da zero, proprio come il compratore medio di una casa non si preoccupa se hai abbattuto l'albero e creato le tue schede. Qualcuno vuole ripetere tutti i loro file di configurazione perché il tuo "upgrade" li riporta di default?

Vuoi mostrare le tue briciole per gli sviluppatori? Costruisci qualcosa che la gente vuole comprare e che include l'intera esperienza utente. È fantastico che tu stia scrivendo un codice di qualità, ma sfortunatamente potresti non ricevere un bonus se non viene rilasciato per la soddisfazione del cliente pagante. Sentiti libero di incolpare il QA, ma la tua azienda non ha ancora abbastanza soldi per pagarti di più.

È qualcosa che è andato di pari passo con Agile & Mischia. Non ci sono ruoli di lavoro chiaramente definiti: ognuno è uno "sviluppatore".

E non sono solo operazioni. Gli sviluppatori devono spesso svolgere analisi di business, test, amministrazione di database e amp; Costruisci ruoli manager: la lista continua.

Al centro del problema c'era ciò che potreste chiamare churn . Con l'aumentare del numero di diversi ruoli coinvolti in un progetto, più incontri, equivoci e amp; scontri di risorse c'erano. Ottenere rapidamente il software di fronte agli utenti è il gioco finale e tutto ciò che può essere in grado di ostacolarlo si è in qualche modo dimenticato.

Questo non è interamente una cosa negativa. Il tuo sviluppatore medio espande le proprie capacità anche se l'inceppamento sta diventando molto sottile ora. Gestisce inoltre gli argomenti tra i programmatori e gli amministratori dei server in merito a dove si trovano i problemi quando le distribuzioni seguono la via della pera. Gli sviluppatori spesso desiderano implementare soluzioni con tecnologia all'avanguardia e gli amministratori dei server spesso non hanno idea di cosa significhi da un POV di amministrazione fino a quando non vengono presentati con il set di installazione.

Le aziende più brillanti e lungimiranti stanno finalmente iniziando a capire che le persone a forma di T sono una buona cosa . Tuttavia, c'è una differenza tra pensare è una buona cosa e aspettarsi che questo avvenga semplicemente magicamente dove una cultura tradizionale era stata precedentemente adottata.

Sono sicuro che ci sono più di un buon motivo per gli sviluppatori di anche per gestire operazioni e controllo di qualità (a volte). Eccone tre:

• Interesse
  Alcuni sviluppatori in realtà vogliono per lavorare su tutti gli aspetti del prodotto. Se sono bravi , e se stanno colmando un vuoto nel team o fornendo un valido supporto ai membri del team esistenti in altri ruoli, non ci può essere alcun motivo per fermarli.
• Costo
  Le grandi aziende possono permettersi impiegati specializzati. Le piccole aziende a volte non possono. Alcuni di questi posti possono assumere sviluppatori 1 o forse 2 o 3 che devono essere in grado di portare semplicemente roba di lavoro fuori dalla porta.
• Dimensioni del progetto
  Non tutti i progetti sono progetti di più persone. Se stai costruendo un'applicazione "piccola", potrebbe essere semplicemente eccessivo avere più di 1 persona che lavori fino alla fine. Di più, piccoli progetti con molti individui che svolgono ruoli specifici sono spaventosi . Nessuno ha abbastanza lavoro da fare - anche se puoi permetterti di tenerli tutti intorno a se stessi per i loro pollici per 6 mesi, quelli buoni non resteranno. Se non si annoiano, si spaventeranno, o realizzerai che stai pagando un bel po 'per niente. In ogni caso, i tuoi impiegati buoni se ne andranno e diranno a tutti di starti alla larga.

... E altri motivi, ne sono sicuro.

"Doversi preoccupare dell'infrastruttura e dei rilasci e del controllo qualità e della cerimonia associata è un'enorme distrazione dalla scrittura di un buon codice"

Nel suo intimo, penso che DevOps dica che preoccuparsi dell'infrastruttura e dei rilasci e che il QA stia scrivendo un buon codice.

In precedenti ruoli che operano in culture non DevOps, ho avuto numerosi problemi che, probabilmente, una cultura DevOps avrebbe potuto prevenire; problemi di prestazioni relativi al codice sviluppato su piattaforme non rappresentative, problemi di codifica dei caratteri in cui gli sviluppatori ignoravano le codifiche dei caratteri utilizzate da un client, istruzioni di distribuzione codificate a mano e insufficienti per il team Ops senza un certo grado di intuizione -Work.

Ora si potrebbe sostenere che una maggiore specializzazione sia sul lato Dev che su Ops ci permette di superare alcuni di questi, ma ancora molti possono essere risolti solo attraverso una condivisione della conoscenza e del lavoro tra i nostri team.

DevOps non deve significare "Dev now do also Ops". Il termine originariamente significava "Dev e le persone che lavorano insieme strettamente in una squadra". fa significa che gli Ops devono diventare più simili ai Devs, perché l'automazione delle cose richiede una sorta di programmazione, e il vecchio modo manuale non la taglia (vedi le altre risposte per un'elaborazione più dettagliata su questo punto).

Da Wikipedia :

DevOps (a clipped compound of development and operations) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes

Quindi secondo me in realtà se tu come Dev hai le stesse vecchie responsabilità e ora anche le responsabilità operative, sembra un errore di calcolo nella parte gestionale. Automatizzando le cose è del tutto possibile che avrete bisogno di meno Ops e quindi vi sono in realtà dei risparmi. Ma DevOps certamente non significa "Liberiamoci da tutti gli Ops e lasciamo che i Devs facciano il lavoro supplementare".

Come spesso accade con le Buzzwords, accade una Diffusione Semantica e improvvisamente la gente pensa "Facciamo in modo che Devs do Ops beh, e immagino che possiamo risparmiare ... "