Cosa significa DevOps IMHO
Contrazione inglese di development, “sviluppo”, e operations, intesta come gestione delle risorse IT di un servizio/prodotto Software.
Il termine indica una cultura e un insieme di pratiche che pongono al centro dell’attenzione la collaborazione tra gli sviluppatori di software e le altre figure dell’IT, i sistemisti in generale.
Solitamente l’approccio DevOps alla gestione dell’IT viene contrapposto allo storico approccio usato in molte organizzazioni in cui lo sviluppo e la produzione sono nettamente separati (divisi in Silos), sia perché le persone appartengono a gruppi di lavoro nettamente separati, sia per i tempi che intercorrono tra lo sviluppo di un componente e la sua messa in produzione.
Lo scopo che un’organizzazione persegue adottando questo approccio e’ il miglioramento in termini di qualità e costi delle proprie attivita’ di sviluppo, rilascio, aggiornamento e recupero in caso di guasti.
Il termine DevOps nasce intorno al 2008 nell’ambito del movimento Agile e si diffonde all’interno di una “comunità di pratica” che lavora su servizi Internet con un approccio innovativo, abbattendo il muro che solitamente, soprattuto nelle organizzazioni medio-grandi, separa sistemisti e sviluppatori. Questo gruppo di persone, tra cui è indispensabile citare Patrick Debois da vita a una intensa attivita’ di divulgazione del proprio approccio, mediante eventi pubblici - i DevOpsDays - e la pubblicazione di libri.
Come tutte le culture e le buone pratiche, e’ difficile parlarne in generale per ogni tipo di organizzazione: sicuramente la presenza di reparti dedicati allo sviluppo e alla gestione dell’IT e’ solitamente piu’ frequente in aziende di medio-grandi dimensioni, ma questo non esclude che anche in aziende con 2-3 sviluppatori e un sistemista part-time l’adozione di questo tipo di cultura porti benefici.
Il primo passo è la condivisione della responsabilità: la gestione degli ambienti di produzione non può essere separata dallo sviluppo e ancora prima dalla progettazione. Affinché ciò che accade in produzione possa contribuire alle scelte progettuali, è necessario che la responsabilità degli ambienti di produzione sia allargata anche al team di sviluppo: questo faciliterà gli sviluppatori a incrementare la propria comprensione del sistema e a sensibilizzarli sulle problematiche operative. I benefici che ci si possono aspettare sono il miglioramento del processo di deploy, la qualità del monitoraggio, la qualità dei log prodotti. Allo stesso tempo i sistemisti devono essere chiamati a liberare il loro tempo per partecipare alle attività di progettazione da un lato e per supportare piu’ attivamente lo sviluppo dall’altro, creando ambienti di sviluppo piu’ vicini alla produzione e migliorando la qualità dei test. L’automazione diventerà il loro migliore alleato, li aiuterà a liberare il loro tempo e li spingerà ad adottare pratiche tipiche dei team di sviluppo (descriere infrastruttura come codice, versionamento del codice, test automatici dell’infrastruttura).
Uno dei componenti cardine di questo approccio e’ l’automazione di tutte le attivita’ inerenti lo sviluppo e la gestione dei servizi, in particolare dei cambiamenti che si introducono dopo la messa in produzione.
C’e’ un legame strettissimo tra l’approccio filosofico DevOps e i tool che si utilizzano per concretizzarlo, al punto che molti vendor hanno introdotto la parola devops in tantissime presentazioni (quando non direttamente nei nomi) dei loro prodotti.
Non è sufficiente adottare uno o più prodotti con il bollino DevOps perché la propria organizzazione abbia dei miglioramenti, ma certamente quando si disidera portare una nuova cultura in un’organizzazione è indispensabile considerare che i primi cambiamenti che saremo portati a considerare saranno proprio i tool adottati per svolgere il proprio lavoro.
L’origine del termine è legato all’abbattimento di barriere tra team distinti, quindi è riduttivo pensare che l’approccio DevOps si risolva nella creazione di un nuovo team o nell’assunzione di un nuovo profilo professionale che prima non esisteva.
Spesso si fa riferimento a DevOps engineer indicando in realtà figure di sviluppatori che, al contrario di quanto accadeva in precedenza, hanno accessi amministrativi e prestano parte del loro tempo ad attività sistematiche su sistemi di produzione. Oppure, al contrario, ci si riferisce a DevOps engineer indicando sistemisti che utilizzano risorse IT in affitto nel cloud, piuttosto che sistemi fisici in un datacenter di proprietà.
La realtà è che in aziende dove non c’era una figura di sistemista, aggiungere DevOps al proprio vocabolario non aiuterà a migliorare i risultati dell’IT aziendale. Allo stesso modo chiamare DevOps il sistemista o team di sistemisti che lavora in modo isolato rispetto allo sviluppo del prodotto, non cambierà la qualità del servizio erogato, anche se si adottano tutti i tool con il “bollino” giusto.
Per introdurre un cambiamento sensibile è necessario sposare i principi dello sviluppo Agile, del Lean Management, della cultura aperta e della conoscenza condivisa: per certi versi DevOps si può considerare una vera e propria estensione dell’approccio Agile allo sviluppo di Software. In questo modo le competenze presenti in azienda tra sviluppatori, sistemisti o figure che hanno un mix di queste competenze possono essere messe a frutto ottenendo un beneficio misurabile.
Ogni contributo a questa pagina è benvenuto, possibilmente preceduto da una discussione, per maggiori informazioni consultare il README.