DevOps è un termine ormai estremamente ricorrente nei vari eventi, blog e pubblicazioni che trattano temi di organizzazione e ottimizzazione delle funzioni IT.

Ad oggi, però, esiste una forte confunsione su quello che realmente si cela dietro questa sigla, e probabilmente, l’unica cosa chiara è il significato letterale della sigla stessa: Dev, ad indicare le attività/reparto di sviluppo, Ops, ad inidicare le attività di operation/sistemisti.

In questo appuntamento, che è solo un’introduzione all’argomento e a cui seguiranno ulteriori approfondimenti, partiamo da un approccio inverso, ovvero andiamo a vedere in 6 punti quello che non è DevOps, secondo l’ottima sintesi fatta da Gene Kim.

1. DevOps non sostituisce un approccio Agile. Quello che cambia è l’estensione del concetto di “Done”: quanto realizzato è considerato completato solo quando i test di accettazione sono superati e quando la soluzione è in erogazione. L’Agile, tipicamente, è concentrato primariamente sugli aspetti dello sviluppo. Bisogna inoltre dire che l’applicazione dell’Agile, pur fortemente consigliata, non è una condizione obbligatoria per poter abbracciare DevOps;
2. DevOps non rimpiazza la metodologia ITIL. Nel marasma generale, spesso si pensa che ITIL, perché legato ad un’ampia documentazione e a diversi livelli di certificazione, non possa andare d’accordo con metodologie meno “burocratizzate”. In realtà ITIL nasce dai risultati sul campo ed è pienamente in sintonia con DevOps, spingendo ad automatizzare quanto più possibile processi, configurazioni, deployment, oltre ad una opportuna governance di Change Management;
3. DevOps non significa NoOps. Esattamente come accaduto per il Cloud, i sistemisti non diventano “inutili” ma innalzano l’asticella delle proprie competenze e delle proprie attività. L’obiettivo è infatti quello di abbattere il Lead Time e migliorare la produttività degli sviluppatori in relazioni al deploy: invece di aprire un ticket ed attendere che Ops si preoccupi del deploy, andando ad interpretare decine di pagine di documentazione, tali attività diventa un servizio di commodity;
4. DevOps non è applicabile solo al mondo dell’Open Source. Anche se il movimento DevOps trova molti casi di successo nel mondo Open Source con i relativi strumenti a disposizione, tutto il mondo dello sviluppo software oggi offre soluzioni per abbracciare questo paradigma e i relativi pattern applicativi: Test Automatizzati, Continuous Integration, Versioning delle Configurazioni degli ambienti, ecc. In questo ambito Microsoft con VSO/TFS e Release Management sta realizzando una delle soluzioni più robuste ed integrate che si possano ritrovare sul mercato;
5. DevOps non significa solo “infrastructure as a code” o automatizzazione. Benché l’automatizzazione sia alla base di molti pattern applicativi DevOps, il cuore di questo approccio è la condivisione degli obiettivi lungo l’intero Stream di Valore che sottende la realizzazione delle soluzioni IT;
6. DevOps non è solo per le Startup e le Unicorn. DevOps è un approccio applicabile a qualsiasi realtà aziendale, soprattutto quelle che riconoscono nell’IT la propria dorsale di supporto (note anche come Horse), al fine di garantire qualità, affidabilità e sicurezza. Chiaramente, in un’azienda strutturata si tratta di un cambiamento radicale che riavvicina la mentalità della divisione IT a quella di una Unicorn al fine di garantire una maggiore efficienza di quanto realizzato in ottica del Valore per il cliente, interno o esterno che sia.

Si tratta di miti che si sfatano facilmente e che consentono di intavolare in modo sereno le prossime discussioni su DevOps, approccio che rappresenta uno stile di azione a cui le organizzazioni guarderanno sempre più con attenzione per rafforzare la propria capacità di rispondere alle crescenti esigenze dei clienti unitamente alla crescente complessità del mondo IT.