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

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

Metterò le mie carte sul tavolo: sono uno sviluppatore e ho lavorato sia in "DevOps" che in non culture. Dover preoccuparsi di infrastrutture, rilasci, QA e la cerimonia associata è una grande distrazione dallo scrivere un buon codice.

Ma l'industria si sta muovendo in questa direzione, quindi quali sono le ragioni? Quali problemi ha generato il "vecchio" modello di specializzazione di ruolo?

Il motivo principale è il cloud.

In passato il codice veniva spedito su floppy disk, quindi su CD, quindi distribuito su un server e quindi distribuito su due server (per resilienza) ... E tutta quella distribuzione poteva essere eseguita manualmente da un essere umano, quindi gli umani sono stati addestrati a farlo.

Oggi, il tuo codice è spesso destinato a dozzine o centinaia di server. Il provisioning, la configurazione e la distribuzione su tali server non possono essere realisticamente eseguiti manualmente da un essere umano. Hai bisogno che i tuoi amministratori di sistema conoscano abbastanza script per automatizzare quel processo, dato che ora stai usando Chef o i suoi simili. Ma francamente, non c'erano abbastanza amministratori di sistema che potevano farlo. Quindi gli sviluppatori sono stati tirati dentro per recuperare il gioco.

E sì, l'aggiunta di più abilità ai requisiti sempre crescenti degli sviluppatori ridurrà naturalmente la loro competenza altrove. L' idea è che, consentendo allo sviluppatore di comprendere il processo di compilazione / rilascio, possono anticipare meglio i problemi o avere l'autonomia per migliorarlo. L'idea è che la qualità di tutto aumenta poiché le vincite del rilascio superano le perdite di scrittura del codice.

Sono scettico sul fatto che il compromesso ne valga la pena tutte le volte che le persone si rendono conto di esserlo.

Ci sono molte ragioni diverse per le varie organizzazioni per passare a DevOps.
Proverò ad elencare quelli che escono spesso.

Ridurre i tempi di modifica del ciclo
Spesso è necessario molto tempo tra una richiesta di modifica e la sua effettiva distribuzione e utilizzo nell'organizzazione. Prima viene pianificato in uno dei cicli di sviluppo dagli sviluppatori e dopo la consegna viene pianificato in uno dei cicli di rilascio delle operazioni. Entrambi i cicli includono test e in caso di problemi riscontrati, entrambi i cicli si resettano. Integrando i dipartimenti di sviluppo e operazioni, possiamo semplificare entrambi i processi.

Problemi relativi a software e hardware
Ricorda il cartone animato Bugs Bunny in cui Bugs e Daffy stanno discutendo se si tratta della stagione delle anatre o dei conigli? Ora immagina di averlo invece realizzato con sviluppatori e operazioni in cui gli sviluppatori sostengono che si tratta di un problema hardware e che le operazioni sostengono che si tratta di un problema software. Per l'utente finale questa è una distinzione senza differenze. Vogliono solo ripararlo.
Riunendo gli sviluppatori e le operazioni dovranno risolvere i problemi. E si può scoprire che si trattava di un problema software e hardware.

Noi vs. loro
In molte aziende la distanza tra tester e sviluppatori stava crescendo perché erano dipartimenti separati e il ciclo di sviluppo stava diventando sempre più formalizzato e standardizzato.
Con l'avvento di Agile, sviluppatori e tester hanno lavorato insieme e abbiamo iniziato a vedere il punto di vista reciproco sul ciclo di sviluppo e forse siamo persino riusciti a rispettarlo.
Qualcosa di simile deve accadere tra sviluppatori e operazioni, poiché man mano che entrambi i campi maturano e i processi si formalizzano e standardizzano ulteriormente, la distanza tra questi reparti sta aumentando. Quindi uno dei problemi con il modello tradizionale è che sembra "noi" contro "loro" sia per gli sviluppatori che per le operazioni. Entrambi non comprendono completamente la difficoltà delle responsabilità dell'altro.

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

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

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

Per molti programmatori, stai scrivendo un software che viene pagato da un utente finale. Scrivere un codice di qualità è una buona cosa, ma è anche qualcosa che i clienti / manager presumono che dovresti sempre fare e fare in fretta. È come dire che un falegname taglia accuratamente le assi, ma stai davvero costruendo qualcosa per cui qualcuno vuole pagare?

DevOps offre agli sviluppatori un maggiore controllo e spera che il loro codice sia in linea con il risultato finale. Chi è più adatto per automatizzare il processo operativo? La soddisfazione dell'utente finale è il principale metro di misurazione. Non solo devi scrivere un codice di qualità, ma deve soddisfare il cliente. Siamo spiacenti, ma nessuno tornerà a utilizzare le righe di codice. A loro non importa se hai costruito il tuo framework ORM da zero proprio come all'acquirente medio di casa non importa se hai tagliato l'albero e creato le tue schede. Qualcuno vuole ripetere tutti i propri file di configurazione perché il tuo "upgrade" li riporta ai valori predefiniti?

Vuoi mostrare le tue costolette da sviluppatore? Crea qualcosa che le persone vogliono acquistare 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 in modo soddisfacente per il 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 & Scrum. Non ci sono più ruoli di lavoro chiaramente definiti: ognuno è uno "sviluppatore".

E non sono solo operazioni. Gli sviluppatori devono spesso assumere analisi di business, test, amministrazione di database e ruoli di manager di build - l'elenco continua.

Al centro del problema c'era quello che potevi chiamare zangola . Con l'aumentare del numero di ruoli diversi coinvolti in un progetto, aumentavano le riunioni, i malintesi e gli scontri di risorse. Avere rapidamente il software di fronte agli utenti è la fine del gioco e tutto ciò che può essere concepibilmente ostacolato è andato un po 'in disparte.

Questa non è del tutto una brutta cosa. Il tuo sviluppatore medio espande le sue abilità, anche se adesso l'inceppamento sta diventando molto sottile. Evita inoltre le discussioni tra i programmatori e gli amministratori del server su dove si trovano i problemi quando le distribuzioni vanno per il verso giusto. Gli sviluppatori spesso vogliono distribuire soluzioni con tecnologia all'avanguardia e gli amministratori del server spesso non hanno idea di cosa significhi 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 rendersi conto che le persone a forma di T sono una buona cosa. Tuttavia, c'è una differenza tra pensare che siano una buona cosa e aspettarsi che ciò accada magicamente dove una cultura tradizionale era stata precedentemente adottata.

Sono sicuro che ci sono più di alcuni buoni motivi per gli sviluppatori di gestire anche le operazioni e il controllo di qualità (a volte). Eccone tre:

• Interesse
  Alcuni sviluppatori vogliono effettivamente lavorare su tutti gli aspetti del prodotto. Se sono bravi a farlo, e se stanno riempiendo un vuoto nella squadra o stanno fornendo un buon supporto ai membri della squadra esistenti in altri ruoli, potrebbe non esserci alcun motivo per fermarli.
• Costo Le
  grandi aziende possono permettersi dipendenti specializzati. Le piccole aziende a volte non possono. Alcuni di questi posti possono assumere 1 o forse 2 o 3 sviluppatori che devono essere semplicemente in grado di far funzionare le cose fuori dalla porta.
• Dimensione del progetto
  Non tutti i progetti sono molti. Se stai costruendo una "piccola" applicazione, potrebbe essere semplicemente eccessivo avere più di 1 persona che la completa fino al completamento. Inoltre, i piccoli progetti con molte persone che svolgono ruoli specifici sono spaventosi . Nessuno ha abbastanza lavoro da fare - anche se puoi permetterti di tenerli tutti intorno per schioccare i pollici per 6 mesi, quelli buoni non rimarranno. Se non si annoiano, si spaventeranno o ti renderai conto che stai pagando un bel po 'per niente. Ad ogni modo, i tuoi bravi impiegati se ne andranno e diranno a tutti di stare lontano da te.

... E altri motivi, ne sono sicuro.

"Dover preoccuparsi di infrastrutture, rilasci, QA e la cerimonia associata è una grande distrazione dalla scrittura di un buon codice"

Fondamentalmente, penso che DevOps affermi che preoccuparsi dell'infrastruttura e delle versioni e del QA IS sta scrivendo un buon codice.

In ruoli precedenti operanti 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 ipotesi -opera.

Ora potresti sostenere che una maggiore specializzazione sia sul lato Dev che su quello Ops ci consente di superare alcuni di questi, ma molti possono essere risolti solo attraverso una condivisione delle conoscenze e del lavoro tra i nostri team.

DevOps non deve significare "Dev now do also Ops". Il termine originariamente significava "le persone Dev e Ops lavorano insieme in una squadra". E lo fa significa che l'Ops persone hanno bisogno di diventare più simili a Devs, perché l'automazione di cose richiede una sorta di programmazione, e il vecchio modo manuale non è tagliato (vedi le altre risposte per un'elaborazione più approfondita su questo punto).

Da Wikipedia :

DevOps (un composto troncato di sviluppo e operazioni) è una cultura, movimento o pratica che enfatizza la collaborazione e la comunicazione sia degli sviluppatori di software che di altri professionisti della tecnologia dell'informazione (IT) mentre automatizza il processo di consegna del software e i cambiamenti dell'infrastruttura

Quindi, a mio avviso, in realtà se tu come Dev hai le stesse vecchie responsabilità e inoltre ora le responsabilità delle Operazioni, questo sembra un errore di calcolo da parte della direzione. Automatizzando le cose è del tutto possibile che occorrano meno persone operanti e quindi ci siano risparmi sui costi. Ma DevOps certamente non significa "Liberiamoci di tutte le persone Ops e lasciamo che gli sviluppatori facciano il lavoro aggiuntivo".

Come spesso accade con Buzzwords, si verifica una semantica diffusione e all'improvviso la gente pensa "Facciamo in modo che anche gli sviluppatori facciano operazioni, e immagino che possiamo risparmiare ..."