Come ingegnere DevOps proveniente da un background operativo, ti sei spostato dalla costruzione e distribuzione manuale di server e software allo scripting dell'installazione del software sui tuoi server con artisti del calibro di BASH, PowerShell, Python ecc. Dopo un po ', ti renderesti conto di come lo scripting interessante è e inizia a esplorare modi più sofisticati per automatizzare la distribuzione .
Alla fine, avresti optato per uno Chef, Puppet, Ansible o altri strumenti di gestione della configurazione per aiutarti a gestire lo stato della tua flotta di sistemi. Man mano che le tue competenze con l'automazione della distribuzione delle applicazioni e della gestione del sistema sono maturate, insieme ai tuoi strumenti, ti sei spostato più di recente nel regno di " Infrastruttura come codice " e lo usi per automatizzare non solo la distribuzione del software ma l'infrastruttura e gli ambienti richiesti per guidare il software durante il passaggio dell'azienda al cloud.
Adesso stai cucinando a gas. Nel tempo ti sono stati presentati i vantaggi dell'utilizzo di strumenti incentrati sullo sviluppatore come il controllo del codice sorgente per gestire i moduli, le ricette e i modelli che compongono il tuo arsenale di strumenti di distribuzione e gestione.
Quando sei passato al team DevOps , sei stato esposto al ciclo di vita dello sviluppo del software e al concetto di integrazione continua . Ragazzo, quegli sviluppatori stavano rilasciando rapidamente le modifiche e per tenerti aggiornato ti sei ritrovato a lavorare più da vicino con gli sviluppatori! Hai sperimentato l'urgenza posta dal team di sviluppo per cambiare le cose TUTTO IL TEMPO che si oppone al vecchio paradigma operativo di " se non è rotto, non aggiustarlo ". Non devi più vantarti del tempo di attività del sistema, sei nell'infrastruttura usa e getta .
Avete notato che il passaggio a DevOps era più che lavorare con gli sviluppatori , o utilizzando nuovi strumenti e tecniche , ma c'era una netta culturale cambiamento nella squadra, quella che permeato attraverso l'organizzazione nel suo complesso. Lavoravi come un team affiatato con responsabilità condivise , strumenti condivisi e obiettivi condivisi .
Hai sfruttato le tue abilità nella distribuzione automatizzata e le hai massaggiate nella pipeline " CICD " orchestrata da un " server di integrazione continua " come Jenkins , Bamboo o Code Pipeline . Ora, quando gli sviluppatori inviano un nuovo codice, i tuoi script, strumenti e modelli resistono a nuovi ambienti su richiesta, innescano quadri di prova per fare le loro cose e abbattono gli ambienti di pre-produzione dopo che le luci verdi sono accese sul rilascio, aderendo al idee di " consegna continua ".
Mentre il nuovo codice si snoda attraverso le fasi CICD, tu, gli sviluppatori e il business acquisisci la sicurezza che l'aggiornamento non si interromperà quando verrà rilasciato alla produzione. C'è ancora molta strada da fare prima che il team arrivi al " dispiegamento continuo ", è comunque necessario accontentarsi dei punti più fini dell'automazione della capacità di schieramento blu / verde e la decisione è principalmente di tipo aziendale. Per il momento sei contento che il numero di chiamate alle 3 del mattino si sia abbassato e che i sev-1 e sev-2 diminuiscano.
Anche se ottieni un sev-1, non stai più trascinando tutti i nottambuli con i gestori che ti respirano la schiena: puoi facilmente rilasciare la versione precedente attraverso la pipeline CICD e riportare il sistema online in breve tempo. Il business ha notato che la stabilità dei sistemi IT è migliorata nonostante la velocità dei cambiamenti .
Ti stupisci del modo in cui gestisci le risorse necessarie per guidare il software nella tua azienda, soprattutto quando ripensi a come era una volta e alla quantità di sangue che hai lasciato sulle rotaie nel datacenter ...
