Nonostante il costante progresso nelle tecnologie di sviluppo, chi si occupa oggi di software development non ha di certo vita facile. In passato, per scrivere e rilasciare il codice di un’applicazione monolite bastavano un buon IDE (Integrated Development Environment, ovvero i comuni ambienti di sviluppo e test integrati, ndr) e qualche passaggio di test. Oggi, con la modernizzazione digitale dei processi e con l’avvento del cloud e di servizi self-service usati da un numero sempre maggiore di utenti, il software tradizionale risulta troppo lento e rigido, e non riesce più a stare al passo. Lo sviluppo applicativo sta evolvendo verso il concetto di azienda piattaforma (o Platform Company) e, di conseguenza, verso nuovi modelli di sviluppo e operations più flessibili e complessi, spesso in conflitto con quelli delle applicazioni legacy. “Il risultato di questa evoluzione è la frammentazione delle tecnologie per lo sviluppo, così come del lavoro del developer – spiega Giulio Roggero, CTO e co-fondatore di Mia-Platform –. Questa condizione può generare incomprensioni all’interno dei team di sviluppo, colli bottiglia, problemi di aggiornamento delle competenze e della qualità dei rilasci”.
Proviene, inoltre, una maggiore pressione da parte del business. Se, nel passato, dopo la creazione di partnership commerciali o fusioni aziendali ci si aspettava che fossero necessari mesi di lavoro per collegare applicazioni e dati, oggi si esige che tutto questo avvenga in pochi giorni. “L’integrazione in tempi così ridotti è realizzabile solo se i sistemi sono scalabili e già pronti per collegarsi via API e con logiche basate su eventi – continua Roggero –. Il business cambia velocemente, e, per stare al passo, servono servizi in cloud e software cloud-ready distribuiti. Sul fronte dello sviluppo, sono necessari strumenti di supporto che semplifichino i processi ed evitino di riprodurre le architetture di vecchi software monolitici”.
L’importanza della developer experience sul portale di sviluppo (Developer Portal)
Il lavoro di chi sviluppa software cloud-native può essere reso più semplice, piacevole e, di conseguenza, produttivo, grazie all’utilizzo di interfacce più chiare e intuitive. “Parliamo di developer experience per descrivere la user experience di chi realizza artefatti software – spiega Roggero –. La semplicità di sviluppo è un aspetto importante per aiutare i developer a passare dai classici IDE ai nuovi tool utilizzati per rilasciare le applicazioni cloud-ready”. Integrazione tra i tool e interfacce migliori fanno la differenza: “Si traducono in minori perdite di tempo, modalità di lavoro più gratificanti ed evitano gli incidenti derivanti da disattenzioni o errori di configurazione”.
La developer experience non ha bisogno necessariamente di una grafica accattivante o di strumenti visuali particolari: “È importante che le interfacce aiutino a gestire i flussi di lavoro – continua Roggero –. Per me, ad esempio, un buon modello di developer experience è la pipeline di Unix (interfaccia a linea di comando, ndr) con cui è possibile realizzare in modo veloce ed elegante compiti complessi, assemblando più componenti. Ciò che abbiamo fatto con il portale di Mia-Platform è tradurre lo stesso livello di funzionalità nei supporti per lo sviluppo”.
Il valore dell’integrazione nel supporto del ciclo di vita del software
La developer experience non può fare a meno di un valido supporto durante l’intero il ciclo di vita del software: dalla scrittura del codice alla messa in produzione, fino al monitoraggio post-delivery e alla gestione di allarmi efficaci. Mentre per la scrittura del codice ci si avvale di IDE sia on-premise che online, il supporto degli altri step del ciclo di vita è più complesso. “Da un lato, vanno eseguiti test di verifica continui, utilizzando tool di deploy secondo modelli diversi, come Bluegreen o Canary release – spiega Roggero –. Dall’altro, va mantenuto un monitoraggio costante per verificare il corretto funzionamento del sistema attraverso l’impostazione di allarmi che si attivano al superamento di determinate soglie oltre le quali si rischia il disastro. In più, vanno previsti sistemi di supporto al troubleshooting, capaci di innescare le sessioni di debugging per mitigare i problemi e creare la documentazione da condividere con il resto del team.
“Il codice deve essere patrimonio di tutti, non solo di chi lo ha scritto – spiega Roggero –. Fare troubleshooting in un sistema distribuito è molto complesso ed è quindi importante condividere i risultati nei diversi contesti di impiego sia allo scopo di eliminare i problemi, sia per attuare contromisure rapide in attesa delle soluzioni. La capacità di raccogliere kpi e altre metriche sui rilasci eseguiti, sugli errori riscontrati e sui tempi di risoluzione permettono alle persone di migliorare”.
Metodi e linee guida a supporto del lavoro in team
“In Mia-Platform sposiamo lo sviluppo agile, legato ai concetti di end-to-end team e Feature team. L’idea è quella di dare supporto a team autonomi che si occupano di piccole porzioni del business aziendale, dal concept alla messa produzione di una funzione specifica”, spiega Roggero. Si tratta di team cross-funzionali IT/business di 6-7 persone che lavorano insieme per soddisfare le esigenze dell’utente finale. “È diverso da accorpare un team di sviluppo che produce codice per qualcun altro, preoccupandosi solo dei tempi assegnati – continua Roggero –. Tutti i membri dei Feature team sono coinvolti nel creare un sistema che funzioni al meglio in risposta a esigenze specifiche”.
Una tipologia di organizzazione ‘più etica’, ma che richiede di moltiplicare il numero dei team di sviluppo. Di conseguenza, aumenta la possibilità che si creino problemi di governance in relazione a sicurezza, linee guida, scelta dei tool e, in generale, sulla qualità finale del software. “Di norma la moltiplicazione dei team comporta una proliferazione di visioni, modelli, tool in uso, e può creare dei colli di bottiglia a livello delle autorizzazioni da parte degli uffici deputati al coordinamento – spiega Roggero. L’approccio che noi riteniamo risolutivo è quello del self-service. I team di sviluppo utilizzano strumenti scelti a livello aziendale sulla base di linee guida condivise”. Nel caso in cui sorga la necessità di introdurre uno strumento aggiuntivo per ottimizzare il lavoro, è possibile presentare una richiesta, la cui approvazione viene discussa da parte di tutti i team. “Questa modalità di evoluzione dell’ecosistema prende le sue origini dal mondo open source, dove le proposte di modifica vengono discusse all’interno della community e, se approvate, entrano a far parte del patrimonio comune”.
Conclusioni
Un portale efficiente per lo sviluppo di software cloud-ready deve offrire una developer experience ottimale che permetta ai team di lavorare meglio insieme, in accordo con i metodi e le linee guida condivise a livello aziendale. “Tutto questo grazie a un approccio agile, che prevede rilasci continui in piccoli batch o continui, la raccolta costante di misurazioni e l’analisi dettagliata dei feedback dell’utente – spiega Roggero –. Il supporto al ciclo di DevOps fa in modo che i rilasci avvengano in modo più fluido e che la qualità del software migliori nel corso del tempo”. Tra le metodologie di sviluppo agile citiamo anche l’ Extreme Programming, che enfatizza la scrittura di codice di qualità: “L’Extreme Programming si basa sui i concetti fondamentali della collective ownership del codice, del test driven development, di cui utilizza le metafore per descrivere i sistemi e i dettami per aumentare la semplicità di sviluppo e la qualità del software”, continua Roggero. È importante sottolineare che gli strumenti di supporto allo sviluppo non si sostituiscono alle competenze dei developer, “ma possono fare da guida, dare suggerimenti che aiutano a far crescere le competenze per migliorare le applicazioni con il cloud e i microservizi, e fare dell’IT il motore del cambiamento di cui il business ha bisogno oggi”.
