I modelli dello sviluppo agile e di DevOps descrivono scenari in cui il flusso di distribuzione delle novità introdotte in modo incrementale nelle applicazioni dai team di sviluppo scorre velocemente e senza intoppi sino all’implementazione sugli endpoint.
In realtà non è sempre così. È la parte finale del flusso che spesso resta legata ai classici modelli a cascata e a lungo termine delle implementazioni software, ponendo il problema – o almeno la questione – del cosiddetto Continuous Deployment.
A livello teorico il Continuous Deployment è l’ultimo stadio nel ciclo dei modelli a sviluppo agile. Prevede la ormai accettata integrazione tra ambienti di sviluppo, test e produzione e riguarda proprio l’implementazione in produzione delle modifiche software. Questa dovrebbe essere automatizzata, attraverso l’uso di semplici script o adottando soluzioni più complesse che vengono definite di ARA (Application Release Automation).
Ciò premesso, non è raro che tutto funzioni come dice la teoria per le fasi di sviluppo e di test ma poi si blocchi alle soglie dell’ambiente di produzione. Qui gli aggiornamenti alle applicazioni o i nuovi sviluppi non vengono implementati in modalità agile ma restano “in pausa” sino a quando lo staff di produzione non ritiene opportuno. Non è una questione di mentalità o resistenza al cambiamento, ci possono essere ragioni anche molto valide per questo freno alla velocità dell’evoluzione software.
Tecnologia e sostenibilità
Molte ragioni che frenano il Continuous Deployment sono legate agli strumenti software che devono gestirlo e a quelli usati per lo sviluppo e il test in modalità agile. C’è, in sintesi, molta differenza fra loro. A volte troppa.
Per le parti di sviluppo e test sono disponibili molti strumenti open source o che si possono usare via cloud in modalità a consumo.
I tool ARA non sono quasi mai così semplici da acquistare e usare: sono tool dedicati che hanno cartellini del prezzo “pesanti” e che richiedono per questo un preciso impegno sia del management ad acquistarli, sia dello staff tecnico ad ammortizzare la spesa. Al momento l’elasticità nell’acquisire nuove soluzioni non è paragonabile tra sviluppo e test da un lato e produzione dall’altro.
In produzione è inoltre necessario garantire una precisa “accountability” degli aggiornamenti applicativi, per ragioni interne ma talvolta anche per questioni di compliance. Alcuni degli approcci usati negli ambienti di sviluppo e test da questo punto di vista non sono adeguati e ancora una volta devono fermarsi prima di entrare in produzione.
Agenti software e script mirati possono ad esempio funzionare molto bene per lo sviluppo e il test, ma non sono molto graditi in produzione. Installare l’ennesimo agente sui server di produzione del datacenter può non essere opportuno, molti script sono troppo “essenziali” per essere tracciabili e consentire operazioni di rollback se qualcosa va storto.
Dal punto di vista meno tecnico, infine, alcuni team di produzione possono avere un vero e proprio problema di sostenibilità nel gestire aggiornamenti frequenti oltre una certa soglia. Se storicamente sono stati in grado di gestire giusto qualche aggiornamento l’anno, non è detto che abbiano abbastanza risorse e staff per passare a qualche update al mese nel Continuous Deployment.
Estendere l’automazione
Il Continuous Deployment, quando è un problema, non è di facile soluzione in questa fase di sviluppo dei tool software. Ci si è concentrati giustamente sulle piattaforme che semplificano la vita di chi sviluppa e di chi testa i software, ma queste non si possono estendere anche alla produzione senza che prima acquisiscano funzioni e caratteristiche che mediamente ancora non hanno.
Ragionare nel senso opposto, ossia estendendo i tool ARA sempre più verso la parte di test e di sviluppo, è possibile ma oggi non semplice. Si tratta di piattaforme “importanti” in grado di garantire il Continuous Deployment nei datacenter con funzioni di application packaging, versioning, configuration management, rollback, auditing e via dicendo. Possono dialogare con strumenti DevOps – i vendor che le offrono spesso hanno anche tool per questo ambito – restano comunque tool complessi, costosi e rigidi per i nuovi modelli di sviluppo.
Al momento, quindi, per molte imprese la soluzione resta quella di gestire il meglio possibile un modello “agile a metà”, con le parti di sviluppo e test che viaggiano a una velocità diversa dalla produzione. Il problema è sentito e quindi gli strumenti nel tempo miglioreranno, arrivando a un approccio trasversale che sia abbastanza solido anche per gli ambienti di produzione.
