Lavorare con i metodi agili porta sicuramente ad avere dei netti miglioramenti sia riguardo alla qualità del prodotto che alla velocità stessa. Ma il passo definitivo per riuscire ad aumentare la velocità nello sviluppo è l’accorciare il tempo che va da Sviluppo a Produzione. Questo è un tema importante e che viene catalogato con il titolo #devops e che vuole far si che il passaggio alla produzione e la collaborazione tra sviluppo e produzione sia un processo continuo e non invece la consegna da un dipartimento all’altro.
Nelle più utilizzate pratiche agili si impiega la Continuous Integration come elemento di integrazione tra il codice sviluppato dal team. Questo è un atto importante e condizione necessaria per riuscire ad evidenziare possibili bug e issues del sistema. La velocità di integrazione del codice è legata al momento in cui si fa una commit sul controllo di versione.
Il fatto di avere un sistema continuo, ci può far pensare oltre e pensare a un sistema di costruzione del software che attui anche un sistema continuo di deploy. Il Cloud con i suoi sistemi e strumenti sta permettendo di poter creare in automatico immagini di una versione del sistema potenzialmente ad ogni commit.
Strumenti come Chef, Puppet per il private/public cloud o Cloud Formation del Cloud di Amazon permettono di poter configuare e dichiarare il modo con il quale la piattaforma debba essere configurata per poi essere esercita in uno degli ambienti identificati (alfa test, beta test, staging, produzione). E’ possibile costruire degli script che in maniera intelligente facciano il provisioning di quello che risiede sul controllo di versione e creino una immagine “production ready”.
Questo presuppone che il sistema abbia un solo modo per poter essere installato e presuppone anche che l’installazione e la configurazione del sistema debba essere completamente automatizzata mediante l’utilizzo di uno dei tool sopracitati. Infatti è un buon principio quello di avere un solo modo per fare il deploy della propria applicazione.
In questo modo l’utilizzo di strumenti di package building e la modernità di soluzioni cloud based (siano esse pubbliche o private) permette di portare a un nuovo livello la mentalità con la quale si può portare in produzione il software.
Il processo di deployment diventa continuo: l’immagine dell’intera applicazione è creata potenzialmente a ogni commit. Ad ogni rilascio si crea un ambiente potenzialmente di produzione e questo può subito essere acceso e messo in alfa o beta testing. Nel momento in cui si lavora su un ambiente, questo è rilasciato come immagine di una istanza esercibile sul cloud.
Attività di quality assurance possono essere fatte e, siccome il cloud rappresenta il datacenter, le istanze possono essere incluse gradualmente nella zona di produzione. Una attività simile permette di configurare i loadbalancer e passare per piccoli passi alla nuova versione, mantenendo la dualità delle applicazioni. Particolare attenzione deve essere posta allo storage e ai database e l’argomento merita una analisi più approfondita.
Nel momento in cui sono ospitate nello stesso ambiente di produzione due immagini formate da due versioni differenti, un set di utenti sarà sulla versione più recente mentre il restante sarà su quella vecchia. E’ necessario governare questa situazione di deploy e portare le instanze della nuova versione a incrementare e decretare invece il termine delle istanze vecchie.
Attraverso l’utilizzo della piattaforma di governance ControlMyCloud.com è possibile andare a definire due policy per gestire le istanze con la vecchia versione e per quelle nuove. Il controllo del rilascio delle applicazioni deve avvenire utilizzando la Control App Right Sizing con la funzionalità Smart Rampdown abilitata. In questo modo è possibile andare a istruire Amazon o l’hypervisor di riferimento di gestire i carichi sul nuovo in maniera elastica e di spegnere gentilmente le istanze vecchie. Le istanze saranno terminate ed escluse dai load balancer nel momento in cui le sessioni utente non saranno più aperte.
Anche il rollback applicativo diventa molto più agevole. Nel caso in cui ci si accorge che una versione sta creando disservizio è possibile fare rollback applicativo governando esattamente al contrario le politiche di Ramp Down.
La gestione dei dati è delicata e un cambio di versione potrebbe impattare molto sopratutto se si utilizzano database relazionali. L’argomento è un argomento molto importante e richiede un approfondimento in una riflessione successiva.
Il processo sopra descritto è orientato a identificare il Continuous Deployment delle applicazioni che è una delle attività che il cloud permette di fare. L’agile software development già ha introdotto il principio del “continuo” ed è giunto il momento di pensare durante lo sviluppo con la testa della produzione. Quindi oltre che pensare ad un sistema che sia user centric, è necessario pensare a come questa applicazione sarà rilasciata e gestita in produzione.
DevOps è una strada che aggiorna e modernizza l’approccio allo sviluppo del software agile e aggiunge quel pezzo che la maturità tecnologica con il cloud permette di aggiungere. Gli strumenti oggi sono tutti a portata di mano ed è necessario stabilire sin dal primo momento un Development Lifecycle che includa l’ambito di produzione e l’esercizio della applicazione stessa.
Per sviluppare e rilasciare una applicazione gli strumenti che utilizziamo sono:
- Git per il versioning;
- Jenkins per la continuous integration;
- Puppet e Cloud Formation per il package building;
- Control My Cloud per la governance
La velocità della iterazione è oggi diventata il campanello di allarme di molti business manager che vedono nei metodi agili e nel cloud una tecnica per riuscire a rispondere alla domanda in tempi corti e ridurre il rischio di impresa.