The DevOps Ways - pt.2 @ DOH19

Nella prima parte di questa serie di post vi ho raccontato dell’applicazione a cui lavoravo e di alcune pratiche che abbiamo adottato:

• Continuous Integration
• Build & Test Automation
• (near) Continuous Delivery (2 deploy in staging al giorno per eseguire e2e test)
• Log Collector
• Telemetry (tramite tracking dei messaggi)

In questa parte vi voglio raccontare la visione che avevo di DevOps e perché essa era sbagliata.

2012 - Visione DevOps n.1

Nel 2012 la mia visione di cosa fosse DevOps, potrebbe essere riassunta nel seguente modo:

• DevOps è un processo per lo sviluppo del software
• le persone nel processo sono principalmente sviluppatori e sysAdmin, ma vi sono anche altre figure coinvolte come tester, _security expert e, in generale, tutti i tecnici che lavorano per scrivere il software e “portarlo” in produzione
• usiamo degli strumenti che rendono il nostro processo un processo DevOps

Proviamo descrivire la mia visione con una metafora e verifichiamo se essa regge. L’uso di metafore fa parte degli strumenti che abbiamo a disposizione.

La metafora che voglio utilizzare è quella dell’arciere.

• il processo è l’arco
• gli arcieri sono le persone, i tecnici, che eseguono il processo
• le frecce che abbiamo a disposizione nella nostra faretra sono gli strumenti

Ora che abbiamo definito i ruoli proviamo a raccontare la mia metafora: io arciere lancio la freccia della Continuous Delivery perché sono DevOps!

Il processo (DevOps) è l’arco, quindi io arciere lancio la freccia perché sono l’arco! ok, non funziona!

Magari la lancio perché sono pigro, quindi lancio la freccia contro me stesso? Abbiamo delle frecce boomerang che le lanci e ti tornano indietro :-)

C’è qualcosa che non mi convince in questa metafora! E’ sbagliata la metafora oppure sto sbagliando qualcosa nella mia visione DevOps?

La risposta la dovreste già immaginare… l’errore è nella visione che avevo di DevOps e c’era qualcosa che non avevo proprio capito! quindi dove sbaglio?

i “come” e i “perché”

Il primo errore è banale e lo faccio spesso, anche in altri ambiti: confondere il “come” con il “perché” e dare più importanza al primo rispetto al secondo! In generale, anche nella vita non lavorativa, è importante saper “come” fare qualcosa, ma è ancora più importante sapere “perché” lo dovremmo fare!

Riassumendo il mio errore in una frase: gli strumenti sono i “come”, gli strumenti NON sono i “perché”

Niente di nuovo

In realtà mi riferisco solo agli strumenti utilizzati da DevOps, non a DevOps stesso! e poi credevo di essere DevOps e sto sbagliando… potrei sbagliare anche il titolo di questa sezione, no?

Le pratiche e gli strumenti utilizzati in ambito DevOps esistono da prima che esistesse DevOps, da prima che fosse coniato il nome e da prima che nascesse il movimento DevOps! Spesso parlando di DevOps si parla di alcuni strumenti, alcune metodologie e identifichiamo chi fa DevOps con chi usa tali strumenti e questo fatto mi ha portato a pensare che usare determinati strumenti ti faccia diventare DevOps.

Come dice un antico proverbio: il tool non fa il DevOps… o forse era “l’abito non fa il monaco”

Bad Name

Patrick Debois coniò il termine DevOps e lui stesso dice che è un pessimo nome! Secondo me, è un bel nome… un ottimo HASHTAG, provate a metterlo come “tagline” in linkedin e vedrete che vi arriveranno un sacco di offerte di lavoro! poi quest’anno va un casino!

Torniamo però al perché è un pessimo nome:

• parla di tecnico: DEVelopment + OPerationS
• non è inclusivo: per esempio security e QA non sono inclusi, quindi serve DevSecOps, DevSecQAOps, *Dev*Ops*
• lo spirito DevOps parla di “business”, ma il nome non ci azzecca nulla con esso

DevOps è un processo che include management e market/customer, non è solo una cosa tra tecnici

Conclusioni pt.2

La mia visione iniziale di DevOps conteneva almeno tre errori e da quegli errori ho imparato le seguenti tre cose:

• gli strumenti sono i “come”, essi NON sono i “perché”
• non siamo DevOps se usiamo un detrminato tool, anche se chi è DevOps lo utilizza
• DevOps è un processo che include *business e market/customer, non è solo una cosa tra tecnici

Per vedere la mia visione aggiornata e scoprire se la metafora regge dovete attendere la terza parte di questa serie, che scriverò la prossima settimana.