Di DevOps si dibatte, oramai, da molto tempo. Chi si prodiga nel definirla una metodologia di sviluppo del software (bah!), chi si affanna a ricondurla ai concetti di lean e agile, chi invece -molto più semanticamente- si limita ad enunciare in sequenza i paradigmi chiave dello sviluppo (Dev) e delle operations (Ops).
Vergogna!
No, nessun insulto ai chi, qui sopra. Vergogna intesa come quel sentimento che, questa perlomeno la mia esperienza, noi tutti proviamo nel “scendere a patti” quando si tratta di praticare il DevOps in contesti professionali. Sì perché, fateci caso, nel privato siamo tutti un po’ Dev e un po’ Ops: il developer professionista che a casa installa un server o che configura i servizi cloud da utilizzare. L’uomo delle operations, invece, che “scripta“, scrive del codice, per poter testare insieme le funzionalità dell’infrastruttura e le applicazioni che ci girano sopra.
Quello che nel privato è già una pratica funzionante, certamente una questione culturale, nel campo professionale diventa una chimera, uno di quegli obiettivi che ritroviamo in tutti gli Executive Summary dei CIO. Uno di quegli obiettivi che, inconsciamente, ci si prefigge di non raggiungere mai.
Caro Dev, non aver paura di consigliare il tuo collega Ops, accetta le sue review del tuo codice. E viceversa.
Abbattiamo queste inutili barriere. Senza vergogna.