Un altro ambito dove la virtualizzazione sta suscitando notevole interesse è lo sviluppo e test del software. La realizzazione di un’applicazione è un processo complesso, fatto di centinaia, spesso migliaia, di iterazioni, che richiede un investimento …
Un altro ambito dove la virtualizzazione sta suscitando notevole interesse è lo sviluppo e test del software. La realizzazione di un’applicazione è un processo complesso, fatto di centinaia, spesso migliaia, di iterazioni, che richiede un investimento massiccio quando l’azienda decide di adottare rigorosi modelli qualitativi.
Tanto per cominciare, gli sviluppatori di una software house devono poter usufruire di postazioni di lavoro con sistemi operativi assolutamente neutri, cioè non contaminati da software di terze parti, librerie o driver di periferiche che possano introdurre variabili inaspettate nell’ambiente di lavoro.
Questo implica che le macchine dove viene sviluppato il software non possono essere le stesse dove i programmatori leggono la posta elettronica, navigano in Internet, installano programmi, e così via.
In più, ogni volta che un progetto termina e ne comincia un altro, l’ambiente di sviluppo dovrebbe essere reinstallato da zero per tornare a una condizione ottimale di lavoro.
Secondariamente, allo sviluppatore è necessario un secondo sistema operativo neutro, identico al primo, dove ogni versione preliminare del software, la cosiddetta “build”, possa essere testata da sola o in concomitanza di altre applicazioni commerciali che probabilmente saranno presenti nella macchina del cliente finale. Se reinstallata sulla precedente, ogni nuova build può alterare le condizioni di partenza dell’ambiente e influenzare il comportamento del software testato. Per questo, anche qui sarebbe necessario reinstallare l’ambiente prima di ogni nuovo test. Ultima, ma non ultima, c’è la problematica di quanti e quali configurazioni supportare per la software house: ogni volta che un’azienda decide di garantire il funzionamento della propria applicazione su un diverso sistema operativo è necessario che abbia un corrispondente ambiente di test per verificare le richieste di assistenza e individuare gli eventuali bug.
Se, per esempio, una software house supporta il suo prodotto su due sistemi operativi, diciamo Microsoft Windows Xp e Vista, e ne afferma la piena compatibilità con una singola applicazione di uso comune, diciamo Microsoft Office, deve già affrontare un investimento imponente: avere un numero di macchine fisiche che possano far girare contemporaneamente tutte le configurazioni indicate sopra (Windows Xp + Office 2003, Windows Xp + Office 2007, Windows Vista + Office 2003, Windows Vista + Office 2007 e così via).
Questo investimento non riguarda solo l’acquisto e la manutenzione delle macchine fisiche, ma si concretizza anche nel numero impressionante di ore/uomo necessarie per reinstallare gli ambienti di sviluppo e test a ogni interazione.
Il costo può essere proibitivo e molto spesso le software house finiscono per violare molte regole fondamentali dello sviluppo e pregiudicare gravemente la qualità e la stabilità dei loro prodotti.
Ancora una volta la virtualizzazione è la chiave per abbattere sia i costi sia la complessità. Innanzitutto abbiamo già detto più volte che l’azione di configurare una nuova macchina virtuale e metterla a disposizione degli sviluppatori è questione di ore, spesso minuti, anziché settimane o mesi. Creare delle nuove Vm per ogni nuovo progetto software è di una semplicità e velocità disarmante. Ma la vera rivoluzione viene da una funzione che praticamente tutti gli hypervisor in commercio oggi offrono: quella che viene chiamata in gergo “snapshot”.
Gli snapshot sono instantanee del sistema operativo che possono essere scattate indipendentemente dal fatto che la virtual machine sia accesa o spenta. Per ogni Vm è possibile scattare molteplici istantanee e lo sviluppatore può passare da una all’altra in pochi secondi.
Grazie a questa tecnologia è, per esempio, possibile salvare uno snapshot della Vm dedicata al test delle nuove build subito dopo la prima installazione del sistema operativo: ogni volta che il test è finito si può tornare pressoché immediatamente allo stato originale, e quindi si ha la garanzia di un ambiente assolutamente neutro.
In più si possono salvare snapshot paralleli per ogni iterazione: per lo sviluppatore, per esempio, ha senso creare uno snapshot della Vm che già contiene una certa build prima e dopo l’installazione di software di terze parti, per verificare se questo provochi conflitti altrimenti difficili da individuare.
In aggiunta a tutto ciò, il fatto di poter avere più macchine virtuali completamente isolate e indipendenti all’interno dello stesso server fisico implica la possibilità di avere una macchina virtuale per ogni ambiente che si vuole supportare al cliente finale.
Se l’azienda ha sottoscritto un contratto volume, come nella maggior parte dei casi, i costi non crescono all’aumentare delle Vm. E giacché le Vm vengono utilizzate solo per il tempo strettamente necessario ai test, un singolo virtualization host può ospitare un numero significativo di ambienti diversi.
Tutte queste operazioni possono essere eseguite manualmente lavorando sulla console di amministrazione degli hypervisor ma per rendere parzialmente automatizzato il processo (ed evitare che gli sviluppatori debbano accedere ai pannelli di controllo dell’intero data center virtuale) è nata una categoria di prodotti che manipola le virtual machine proprio allo scopo di semplificare il processo di sviluppo del software. Quel processo che oggi chiamiamo “Virtual lab automation” (Vla).
Il numero di player in questo segmento di mercato è ancora molto limitato ma ci sono notevoli potenzialità di crescita.
