Risposte:
Il punto di DevOps è che lo sviluppo non dovrebbe opporsi alle operazioni, invece dovrebbero supportarsi a vicenda.
Tradizionalmente, a causa delle distribuzioni a cascata e degli aggiornamenti su larga scala, lo sviluppo causerebbe operazioni con una varietà di problemi durante l'implementazione a causa di test inadeguati, modifica degli ambienti server, l'elenco potrebbe continuare all'infinito. In sostanza, gli aggiornamenti erano troppo grandi per consentire al team operativo di implementarli in modo efficace senza che si presentassero problemi nel processo. Questi problemi potrebbero essere il motivo per cui ritieni che lo sviluppo si opponga alle operazioni .
D'altra parte, DevOps lavora per ridurre le dimensioni dell'aggiornamento, diminuire gli ambienti rigidi e generalmente migliorare il trasferimento dell'applicazione tra lo sviluppo e le operazioni aumentando il numero di volte che si verifica il trasferimento ogni anno. Con l'aumentare del numero di implementazioni si ottengono meno mal di testa per le operazioni, poiché hanno automatizzato una grande quantità di lavoro necessario per aggiornare i prodotti, oppure anticipano e preparano meglio gli aggiornamenti.
Tldr: DevOps mira a annullare la teoria secondo cui lo sviluppo si oppone alle operazioni creando una mentalità in cui operazioni e sviluppo collaborano per distribuire frequentemente prodotti in modo tempestivo e facilmente riproducibile.
Penso che tu abbia già ricevuto alcune risposte complete, ma hai detto che il tuo inglese non è eccezionale, quindi proverò a fornire una risposta molto breve e comprensibile:
Queste due cose sono in conflitto. Detto questo, lo sviluppo e le operazioni non dovrebbero opporsi. Dovrebbero lavorare insieme per assicurarsi che entrambi gli obiettivi possano essere raggiunti. Questo è lo scopo di DevOps.
La tensione tra sviluppo e operazioni è spesso causata dal disallineamento degli incentivi e dai tentativi di ottimizzazione all'interno del team.
Gli sviluppatori sono spesso giudicati in base alla velocità e alla quantità di problemi che possono superare e uniti nel repository di codice e la loro ricompensa spesso non è legata a quel codice che funziona o funziona correttamente. Molto meno ridimensionamento, prestazioni e altri fattori.
Le operazioni vengono spesso giudicate in base alla stabilità dell'ambiente e al funzionamento del codice nella produzione, ma raramente sulla qualità del processo per apportare rapidamente modifiche.
Ciò crea il problema in cui gli sviluppatori sono incentivati a creare molto codice e a buttarlo oltre il muro per il team operativo e il team operativo ha l'incentivo ad accettare il minor numero possibile di cambiamenti per garantire la stabilità dell'ambiente.
DevOps è in un certo senso l'insieme di soluzioni a questo problema:
La maggior parte delle organizzazioni affronta la complessità suddividendo la propria organizzazione in parti funzionali e chiedendo a ciascuna parte di capire come migliorare se stessa. Questo è spesso chiamato approccio "silo".
È importante capire perché questo approccio basato sul silos blocca il successo dell'azienda e spesso non riesce a migliorare l'organizzazione nel suo complesso. E non influisce solo sullo sviluppo e sulle operazioni: influisce su tutti gli altri silos funzionali all'interno di una grande organizzazione come team di controllo qualità, finanza, gestione di prodotti e progetti.
Poiché ai gestori di ciascun silo funzionale viene chiesto di migliorare riducendo i costi o aumentando la velocità, la loro reazione è spesso:
Con queste reazioni tipiche, ogni dirigente che lancia un piccolo sforzo di miglioramento viene raramente accolto con entusiasmo. I manager si trovano in una forte concorrenza con altre aree funzionali rispetto alle risorse necessarie per eseguire i loro miglioramenti. Quindi, non c'è da stupirsi che il comando di migliorare intensifichi battaglie interfunzionali!
Anche quando un manager completa la sua parte di un progetto di miglioramento, incontra poi altre aree funzionali e altre organizzazioni (fornitori, appaltatori, ecc ...) che non hanno svolto il loro lavoro. Ciò riduce o annulla totalmente i risultati.
Questa tensione interfunzionale non si limita agli sforzi di miglioramento. È nel cuore del processo decisionale quotidiano e del giudizio sull'efficacia della gestione all'interno di un'organizzazione. Ecco un esempio di vita reale:
A un direttore finanziario è stato detto "migliora". Decise di bloccare gli appaltatori che assumevano un costo superiore al prezzo nominale accettato sul mercato. Ha implementato la nuova politica e ha affermato di aver risparmiato $ 1 milione di dollari quest'anno. Con gli sviluppatori e l'IT incapaci di assumere appaltatori per aiutarli a utilizzare container e orchestrazione di container poiché questi appaltatori sono costosi. Il responsabile delle operazioni IT nella stessa azienda ha calcolato che non migliorare la propria infrastruttura costava alla società ben oltre $ 100.000 in spese extra ogni mese. A quel ritmo, i risparmi annui degli appaltatori assunti venivano consumati prima della fine dell'anno.
Potete immaginare che la relazione tra queste due aree funzionali non fosse esattamente amorevole.
Questi conflitti interfunzionali sono guidati dall'approccio del silo, in cui l'organizzazione misura ogni silo in miglioramento in modo indipendente. Se sei un centro di costo, il miglioramento significa naturalmente maggiore efficienza o riduzione dei costi all'interno del tuo silo.
In questo quadro di riferimento, i costi sono visti come obbedire alla regola "additiva". I costi di ciascun silo sommati sono pari al costo totale dell'organizzazione. Pertanto, i manager vedono qualsiasi riduzione dei costi nella loro area come "buona", dal momento che vedono una traduzione diretta in risparmi sui costi per l'intera azienda. In questo quadro di riferimento, gli sforzi di miglioramento sono diffusi ovunque per attaccare costi e sprechi in tutta l'organizzazione.
Un ottimo esempio quando i team di sviluppo iniziano a lavorare su Agile e inviano il codice a QA e Operations ogni due settimane anziché ogni trimestre come una volta. Il QA e le operazioni non sono pronti per tale modifica e sono accusati di rallentare. Ancora una volta, questo non contribuisce molto all'amore tra le persone nello sviluppo e nelle operazioni.