Ho realizzato / creato molte presentazioni relative a SCM e ora sto cercando di "aggiornarlo" a un successore di DevOps.

Quello che cerco sempre di fare nelle mie presentazioni, è di elaborare una diapositiva introduttiva che in qualche modo includa il messaggio che voglio consegnare (e che poi elaboro nel resto della mia presentazione). Nel fare ciò, provo a rispondere alla mia domanda come "Quali sono le mie 1-3 frasi che vorrei usare se avessi 10-20 secondi (solo!) Per spiegarlo a qualcuno che non conosce? * ".

Pensavo di sapere cosa significa effettivamente DevOps e di cosa si tratta. Ma ho visto alcuni usi / contesti bizzarri di DevOps (anche su DevOps.SE ...). Mi chiedo se forse ciò che penso sia DevOps, sia completamente sbagliato.

Quindi, quale è generalmente la definizione di DevOps?

DevOps in breve

Da Wikipedia :

DevOps (un composto troncato di " software DEV elopment " e " Information Technology OP perazione S ") è un termine usato per riferirsi a un insieme di pratiche che enfatizzano la collaborazione e la comunicazione di entrambi gli sviluppatori di software e la tecnologia dell'informazione (IT) professionisti automatizzando il processo di consegna del software e i cambiamenti dell'infrastruttura.

Mira a stabilire una cultura e un ambiente in cui la costruzione , il test e il rilascio di software possano avvenire rapidamente, frequentemente e in modo più affidabile.

Dalla panoramica :

Diagramma di Venn che mostra DevOps come intersezione di sviluppo (ingegneria del software), operazioni e controllo qualità (QA)

Mentre non esiste un unico "strumento" per DevOps, ma piuttosto un insieme di strumenti, noto anche come toolchain DevOps :

Illustrazione che mostra le fasi in una toolchain DevOps

Illustrazioni di DevOps

Di seguito sono riportate alcune citazioni da alcune delle domande su DevOps.SE , che sembrano in qualche modo adattarsi / confermare parte della descrizione di DevOps sopra:

• Da ' Qual è la differenza tra SRE e DevOps? ':

  ... DevOps riguarda il mantenimento del codice ...

• Da (una risposta a) ' Come posso assumere un buon DevOps, adatto alla mia azienda? ':

  ... È un'incredulità comune che "DevOps" sia un ruolo in un'azienda. La parola indica semplicemente un cambiamento organizzativo nelle società di software ...

• Da ' La mia organizzazione deve adottare Agile Soft. Dev. prima di adottare DevOps? ':

  ... ci sono ancora organizzazioni che non praticano Agile nello sviluppo del software, che potrebbero essere interessate all'adozione di DevOps ...

DevOps NON è un ruolo

Di seguito sono riportate alcune citazioni da alcune delle domande su DevOps.SE , che sembrano illustrare che DevOps NON è un ruolo:

• Da (una risposta a) ' Qual è la differenza tra Sysadmin e DevOps Engineer? ':

  ... DevOps non è un ruolo (se usato come tale è più una parola d'ordine che un ruolo reale).

• Da (una risposta a) ' Come posso assumere un buon DevOps, adatto alla mia azienda? ':

  ... È un'incredulità comune che "DevOps" sia un ruolo in un'azienda. La parola indica semplicemente un cambiamento organizzativo nelle società di software ...

Ho praticato e fornito consulenza su DevOps come consulente con diversi clienti da quasi cinque anni ormai, prima della mia attuale posizione, ho ricoperto ruoli nello sviluppo di software, operazioni web e amministrazione di sistemi. Nella mia esperienza personale DevOps è disponibile in molti gusti.

Modelli di organizzazione

DevOps Antipatterns:

• NoOps e NoDevs - non strettamente DevOps nel senso più stretto, tuttavia, questi team creano e gestiscono software senza una linea di demarcazione tra Sviluppo e Operazioni. Le sfide con questi team scendono alla maturità, i team di sviluppo possono essere sviluppatori di software esperti ma operatori alle prime armi e viceversa.

• DevOps Bridge : è qui che uno o più team hanno la responsabilità di prendere il lavoro dei team di sviluppo e di " produrlo " per renderlo operativo. La sfida giunge ora a due distinzioni, vale a dire Sviluppo → DevOps e DevOps → Operazioni.

• Il team DevOps - questo può, probabilmente, funzionare se il team ha la responsabilità di costruire strumenti che supportano il modello operativo abilitato DevOps, tuttavia, dovrebbe probabilmente essere chiamato "Team di strumenti" o "Team di piattaforma".

Modelli DevOps:

• DevOps integrati - più comunemente denominati Platform Engineering, in base al quale c'è qualcuno all'interno del team che è responsabile ma non è responsabile della fornitura di automazione, strumenti e infrastrutture per il provisioning e la distribuzione della soluzione, a volte anche con il funzionamento del software - nella mia mente , è quest'ultimo che in realtà è rappresentativo di DevOps.

• DevOps istituzionalizzati - in cui un team di progetto è responsabile sia dello sviluppo che del funzionamento di un pacchetto software che crea proprietà condivise e cicli di feedback positivi.

pratiche

La pratica effettiva di DevOps si basa su molte altre pratiche, vale a dire:

• Consegna agile
• Integrazione continua
• Consegna continua
• Distribuzione continua

Ognuna delle pratiche di cui sopra si basa sull'altra, è possibile non seguire una pratica, tuttavia significa che manca un ciclo di feedback importante che potrebbe essere indicativo di una "opportunità mancata". Il principale fattore di differenziazione tra seguire una qualsiasi delle altre pratiche e DevOps è il funzionamento del software in produzione .

I tre modi

Nel progetto Phoenix, Gene Kim e i suoi coautori descrivono i tre modi di DevOps :

Sistemi di pensiero

The First Way enfatizza le prestazioni dell'intero sistema, in contrapposizione alle prestazioni di un determinato silo di lavoro o di reparto: questa può essere una divisione grande (ad es. Sviluppo o Operazioni IT) o piccola come un singolo contributore (ad es. , uno sviluppatore, amministratore di sistema).

Nella mia esperienza, iniziare a convincere gli sviluppatori a considerare le preoccupazioni operative e i requisiti non funzionali raggiunge questo obiettivo. Questo fa molto parte degli aspetti culturali di DevOps.

Amplificazione dei circuiti di retroazione

Il secondo modo riguarda la creazione di loop di feedback da destra a sinistra. L'obiettivo di quasi tutte le iniziative di miglioramento del processo è abbreviare e amplificare i circuiti di feedback in modo da poter apportare continuamente le correzioni necessarie.

In genere ottengo questo risultato attraverso l'integrazione / consegna continua / distribuzione e il monitoraggio e gli avvisi condivisi, quindi si adatta perfettamente al componente strumenti di DevOps.

Cultura della sperimentazione e dell'apprendimento continui

La terza via riguarda la creazione di una cultura che promuova due cose: la sperimentazione continua, l'assunzione di rischi e l'apprendimento dal fallimento; e capire che la ripetizione e la pratica sono il prerequisito per la padronanza.

Questo si adatta molto allo spazio culturale , sebbene dipenda fortemente dagli strumenti e dai processi per consentire alla cultura di crescere.

Ho sentito molte, molte diverse definizioni di DevOps. Loro includono:

• Sviluppatori che gestiscono attività operative
• Una persona che fa il doppio del lavoro (nella stessa quantità di tempo)
• Sviluppatori e team operativi che collaborano tra loro
• Le operazioni funzionano per gli strumenti per sviluppatori (sulla scia di "Web Ops")
• Un titolo di lavoro per qualcuno che crea e mantiene strumenti per sviluppatori
• L'uso dell'automazione nelle operazioni
• L'uso di cloud pubblici nelle operazioni
• Un lavoro che combina aspetti di operazioni, sviluppo e garanzia della qualità
• Un lavoro che implica aiutare i team di sviluppo e operativi a lavorare insieme
• Una filosofia per abbattere le barriere tra i team
• Trattare l'infrastruttura come codice
• Cosa ottieni quando gli ex ingegneri del software passano alle operazioni
• Una parola d'ordine completamente insignificante

Non c'è consenso pubblico su cosa sia realmente DevOps . Qualche anno fa abbiamo avuto problemi simili con "Agile", e questo ha una definizione scritta .

Quando introduco i tuoi concetti a un nuovo arrivato, mi concentro sull'introduzione dei concetti, piuttosto che sull'applicazione di un'etichetta, altrimenti finiranno per ascoltare definizioni contrastanti e confondersi. Ad esempio, se stai cercando di parlare di infrastruttura come codice , di 'loro che stai parlando di infrastruttura come codice. Quanto più specifico puoi essere, tanto meglio, come anche con definizioni concordate, la maggior parte delle aziende si concentra maggiormente su alcune parti di una filosofia.

La definizione che uso sempre in questa situazione è la seguente:

“Una cultura della creazione di software che enfatizza la comunicazione e la collaborazione tra lo sviluppo del software e i team operativi mentre automatizza il processo di consegna del software e i cambiamenti dell'infrastruttura. L'obiettivo di DevOps è rendere il processo di costruzione, test e distribuzione del software il più frequente, veloce e possibile. "

Tuttavia, insieme alla definizione, è anche importante che capiscano PERCHÉ abbiamo bisogno di DevOps. Assicurati di dire loro che DevOps mitiga più rapidamente i difetti del software, consente una migliore gestione delle risorse, meno errori umani, un migliore controllo della versione, un ambiente operativo stabile ecc.

Nel seguente documento di ricerca scientifica per esplorare esattamente questa domanda, "Cos'è DevOps", la definizione derivata proposta di DevOps è:

DevOps è una metodologia di sviluppo volta a colmare il divario tra Sviluppo (Sviluppo) e Operazioni (Operazioni), enfatizzando la comunicazione e la collaborazione, l'integrazione continua, la garanzia della qualità e la consegna con distribuzione automatizzata utilizzando una serie di pratiche di sviluppo.

[Jabbari et al.] "Cos'è DevOps ?: Uno studio di mappatura sistematica su definizioni e pratiche" (2016)

Devops è la pratica di sviluppo della scrittura di applicazioni il cui dominio aziendale è operazioni. Laddove la maggior parte dello sviluppo di applicazioni si concentra sulla creazione di applicazioni che finanziano o assistenza sanitaria o logistica o video di gatti, devops si concentra su applicazioni che consentono build, implementazioni, monitoraggio e raccolta di metriche.

L'obiettivo prioritario dovrebbe essere sempre quello di consentire ai decisori di prendere decisioni . Immagina l'applicazione mobile della tua banca. Quando richiedi un trasferimento, succede quando premi il pulsante. Hai preso una decisione, poi hai preso la decisione. Stessa cosa con le tue operazioni. Quando la persona appropriata decide che un lavoro è pronto per essere distribuito alla produzione, dovrebbe essere in grado di premere un pulsante e "Le cose giuste accadono". Allo stesso modo, dovrebbero avere tutte le informazioni necessarie per prendere le giuste decisioni aziendali.

Non si tratta di dare agli uomini d'affari l'accesso shell ai server - questo è uno scopo confuso con l'implementazione. Si tratta di fornire le manopole e le leve giuste con le giuste informazioni e le giuste ringhiere alle persone giuste in modo che i responsabili delle decisioni siano coloro che prendono le decisioni.