Il termine DevOps indica una nuova disciplina dell’IT, il termine nasce come contrazione delle parole inglesi “Developer” e “Operational”.
Il DevOps è di fatto una nuova metodologia che ha come scopo l’abbattimento delle barriere comunicative, la prima volta che venne usato questo termine, è stato nella Agile Toronto Conference del 2008, nella presentazione di Patrick Debois.
L’idea era semplice, usare l’Agile per mettere insieme tutte le aree di sviluppo, per aumentare la qualità del software prodotto. Dopo la conferenza l’inziativa legata al DevOps si è evoluta e nel 2013 viene pubblicato il libro must del DevOps, “The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win”, l’uscita del libro rappresenta la consacrazione del movimento DevOps, sempre più aziende iniziano il viaggio che le porta all’adozione del DevOps. Il DevOps è più una disciplina che altro, ed essendo nata dall’idea del Agile, per essere effettiva deve essere accettata e promossa dal management aziendale.Questo spesso si traduce nell’introduzione di una nuova figura chiamata DevOps Engineer.
Cosa e’ un DevOps Engineer
Capita spesso di trovare definizioni contrastanti riguardo un DevOps Engineer, iniziamo con il dire che un DevOps Engineer, non è un System Engineer o un Sys Admin, un DevOps, non è Software Engineer, un DevOps Engineer, è una figura ibrida, deve avere competenze di sviluppo, deve essere in grado di programmare, non scrivere semplici script, deve avere competenze architetturali, deve capire se l’architettura Software e Hardware è valida o no, e deve avere conoscenze di System Engineering. Tutto questo perché il ruolo del DevOps, è quello di ridurre il “time to market”, cioè il tempo che intercorre tra l’identificazione di un requisito e il rilascio dello stesso.
Componenti fondamentali del devops
Come ogni disciplina, il DevOps ha alcune componenti fondamentali che non possono essere tralasciate, vediamo di riassumere per punti cosa bisogna fare per rendere il DevOps valido per l’azienda:
- I manager devono accettare il cambiamento richiesto dal DevOps
- I Developer devono essere responsabili di quello che viene rilasciato in produzione, in caso di errore dovrebbe esserci sempre un developer che affianca chi mantiene l’applicazione
- Chi si occupa di mantenere il software deve essere considerato un “first class citizen” durante le decisioni che riguardano il software devono essere interpellati, lo scopo è controllare ad esempio che i log siano chiari, e che le librerie che si vogliono usare siano compatibili con il sistema
- Mettere in essere politiche di Continous Integration e Continous Delivery
- Ridurre le barriere di comunicazione tra team di sviluppo e sistemisti
- Monitorare in maniera efficiente tutte le componenti aziendali per ridurre gli errori
- Automatizzare quanto piu’ possibile il bug fixing sui sistemi
Tutte queste componenti devono essere la base su cui instaurare il processo di DevOps in azienda, ovviamente non e’ un cambio facile in particolare per quanto riguarda la comunicazione tra Developer e Sistemisti, per anni i Developer sviluppavano e poi lasciavano ai Sistemisti il compito di mantenere in produzione il lavoro, questo rallenta il processo di rilascio, il DevOps vuole ridurre questo tempo.
come attuare il processo di devops
Come abbiamo visto il DevOps richiede specifici steps per essere efficace in azienda, la maggior parte dei cambiamenti riguardano l’abbattimento di barriere e l’aumento della comunicazione tra i diversi dipartimenti. In aggiunta vengono associate le pratiche della Continous Integration e Delivery per migliorare la qualita’ del software. Tutte questi cambiamenti portano la naturale scelta verso le metodologie agile, il perché è legato nella natura stessa del DevOps, non dobbiamo dimenticare che il DevOps nasce di fatto nel 2008 in una conferenza Agile. Se vogliamo sintetizzare in punti come attuare un processo di DevOps possiamo racchiuderli in questi punti:
- Il team di sviluppo deve iniziare ad usare la metologia Agile, con rilasci veloci, Sprint, e Unit Test
- Durante lo sviluppo, si deve applicare il principio della Continous Integration, ogni commit del codice nel repository deve essere testata, tramite unit test, e successivamente installata in un server di test dove i QA Engineer potranno effettuare test generali
- Quando si sviluppa una nuova feature, è bene coinvolgere nel disegno del software e della architettura il team che si occuperà del mantenimento del software, questo perché saranno in grado di indicare se quella specifica libreria e’ compatibile o meno con il sistema, in caso non sia compatibile si può vedere se aggiornare il sistema o cambiare libreria, e allo stesso tempo saranno in grado di dare un feedback per quanto riguarda i log
- Instituire la figura del “Developer On Call” che affiancherà il Sistemista normalmente on call, questo per aiutare a trovare più velocemente una soluzione durante un problema
- Attuare sistemi di monitoraggio del software, a cui accederanno anche i developer, in questo modo è più facile trovare condizioni di errore e automatizzare i processi per la soluzione
- Automatizzare i metodi di rilascio del software, minore intervento umano significa minore rischio di errore.
Tutte questi cambiamenti abbracciano l’intero processo di sviluppo con il solo scopo di ridurre il time to market e migliorare la qualità del software, il software viene testato di fatto ad ogni cambio, il che riduce il numero di bug al momento dell’effettivo rilascio.
conclusione
Come abbiamo visto il DevOps è una disciplina che abbraccia l’intero processo di sviluppo aziendale, è sbagliato pensare ad un DevpOps Engineer come un sistemista o un software engineer, un DevOps Engineer è la figura che si occupa di mantenere/definire i processi e le procedure necessarie all’attuazione del DevOps stesso. Se vogliamo pensare qualcosa di attuale, un DevOps Engineer può essere assimilato ad un SRE, Site Reliability Engineer, definita da Google, in cui deve essere in grado di scrivere software, come un software engineer, essere in grado di definire e rivedere architetture software e hardware, ed essere in grado di sistemare problemi in produzione e una volta identificata la root cause, scrivere un pezzo di codice per automatizzare la soluzione, oppure per evitare che accada ancora.
Bibliografia
http://www.jedi.be/blog/2008/10/09/agile-2008-toronto-agile-infrastructure-and-operations-presentation/
