Le aziende automobilistiche stanno inserendo hot spot Wi-Fi nelle vetture. La tecnologia degli orologi sta passando dagli ingranaggi alle schede madre. Persino i distributori automatici di bibite sono passati da macchine elementari a dispositivi dotati di strumenti con interfacce utente touch-screen. Insomma, nell'economia delle applicazioni, ogni azienda dipenderà sempre più dal software con non poche ripercussioni che già oggi si stanno concretizzando all’interno dei dipartimenti It nell’ambito dello sviluppo software. La Digital Transformation porta il software all’interno dei servizi, dei processi, dei prodotti cambiando così, attraverso nuovi e differenti requisiti, il modo in cui le applicazioni vengono sviluppate, sottoposte a test, trasferite da un ambiente all'altro e rilasciate in produzione.
I processi e i sistemi di delivery delle applicazioni, in numerose aziende, sono stati implementati quando l'It doveva preparare soltanto una release all’anno o a semestre. Uno scenario che sembra del tutto irreale se si pensa alle attuali pressioni dei mercati, del business e degli utenti in termini di frequenza e velocità di rilascio di servizi digitali innovativi. Un gap che pone una serie di sfide a livello di sviluppo test, automazione e soddisfazione dei clienti che si frappongono tra l’It e gli obiettivi di Digital Transformation dell’azienda.
Nell’eBook sulla Continuous Delivery di CA Technologies intitolato “Quattro sfide critiche associate alla delivery di software nell'economia delle applicazioni” se ne analizzano i dettagli. Qui ne offriamo una rapida esemplificazione.
Sfida n.1: eliminare i vincoli dei colli di bottiglia
Le applicazioni attuali combinano codice interno, microservizi di terze parti, API e interfacce utente spesso sviluppati contemporaneamente da team distinti, introducendo un elemento di complessità. Quando creano codice per correggere un errore, aggiungere nuove funzionalità o eseguire l'integrazione con un altro servizio, gli sviluppatori spesso devono poter accedere al codice su cui altri sviluppatori stanno lavorando perché i componenti sono interdipendenti. Inoltre, poiché i team lavorano più velocemente secondo logiche e metodologie Agile, ogni giorno rilasciano ‘build’ (pacchetti di codice) a un ritmo accelerato, ciascuno dei quali richiede la creazione e la configurazione di un ambiente. Questa operazione, se eseguita manualmente, può richiedere tempi lunghi ed è inoltre possibile che alcune risorse non siano disponibili nel momento in cui vengono richieste.
Sfida n.2: test manuali e insufficienti
Dopo le prime fasi di sviluppo, seguendo processi Agile e DevOps ma in generale anche attraverso approcci di tipo più tradizionale, iniziano i test funzionali e le analisi di user acceptance per i quali i cosiddetti quality assurance manager devono sviluppare un piano di test. Tale piano comprende gli elementi su cui eseguire il test, la relativa modalità e gli ambienti che devono essere creati e/o configurati. I team raramente hanno accesso a test cosiddetti ‘live like’ (cioè su ambienti del tutto paragonabili a quelli della produzione) e devono ‘assemblare manualmente’ i set di dati o utilizzarne uno esistente che può non permettere una vera e propria simulazione a livello di produzione. Tutte queste attività, in moltissime realtà ancora gestite manualmente, generano ritardi che possono sommarsi e determinare il mancato rispetto delle date di delivery.
Sfida n. 3: automazione in silos
Con la crescente complessità dello sviluppo delle applicazioni, i team It hanno adottato un numero sempre maggiore di strumenti per supportare le attività lungo i processi del ciclo di sviluppo del software. Da ambienti di sviluppo integrato (Ide) come Eclipse e sistemi di integrazione continua (Ci) come Jenkins, a strumenti di gestione dei container come Docker, o di configurazione come Chef… insomma, anche dal punto di vista di adozione delle tecnologie, la complessità è crescente. Sebbene siano stati progettati per semplificare o automatizzare determinate attività individuali, infatti, questi strumenti richiedono spesso transizioni e passaggi manuali che generano ritardi.
Sfida n.4: aspettative degli utenti sempre più elevate
I clienti si aspettano di ricevere software innovativo e facile da usare, indipendentemente dal tipo di applicazione e dal contesto di utilizzo (luogo o device). La sfida reale qui è che la maggior parte dei team di sviluppo non ha una visione dettagliata del modo in cui i clienti interagiscono con le applicazioni. E nemmeno visibilità sulle performance dell'applicazione necessaria per promuoverne il miglioramento continuo e significativo nel corso del tempo. Senza una visione di tutti i componenti e servizi che contribuiscono alla customer experience, i team It non sono in grado di identificare in modo proattivo i problemi o individuare rapidamente le cause di eventuali problematiche quando queste si verificano.
Verso la Continuous Delivery come risposta metodologica
Nel documento citato per ciascuna sfida si trovano alcuni spunti e suggerimenti per superarle ma il fulcro di tutto ruota attorno alla Continuous Delivery, un obiettivo apparentemente semplice ma che richiede una nuova mentalità su persone, processi e tecnologie che guidano tutte le attività di delivery delle applicazioni.
Un approccio alla Continuous Delivery inizia con la valutazione corretta ‘dello stato attuale’ del ciclo di sviluppo del software e include alcuni passaggi successivi, quali:
• Sviluppare una solida conoscenza dell'intero processo di delivery delle applicazioni, degli strumenti, degli ambienti e di tutte le parti interessate
• Identificare le tecniche strategiche e le aree del business che rappresentano punti deboli e i maggiori ostacoli
• Individuare i processi manuali e i potenziali candidati per l'automazione
• Valutare gli strumenti attuali per la sovrapposizione e la ridondanza a livello funzionale
• Creare una visione e un piano per uno stato futuro desiderato, per passare alle fasi successive senza ‘intoppi’.
Secondo le valutazioni di Forrester, si legge nell’eBook, l’approccio alla Continuous Delivery è più che mai strategico per il rapido rilascio del software: “l'implementazione di una pipeline completamente automatizzata è una realtà rara, ma in crescita”, scrivono gli analisti.
