AppQuality (Unguess da gennaio 2022) è la soluzione che aiuta le aziende a creare prodotti e servizi user-centrici coinvolgendo la sua community (il Crowd) di persone reali in tutte le fasi del processo, dal design allo sviluppo fino al testing. Il servizio offerto ha l’obiettivo di portare sul mercato prodotti e servizi con un’esperienza d’uso memorabile per gli utenti reali.
Accompagnare il Cliente lungo il percorso di adozione di un approccio Cloud Native.
Il Cloud Native Journey è una trasformazione che interessa l’intero ciclo di produzione del software. L’azienda e il team che decidono di intraprendere il viaggio sanno (o scoprono ben presto) che dei cambiamenti rilevanti sono in arrivo: questa è sicuramente la sfida più grande e per iniziarla al meglio è necessaria una conoscenza approfondita dell’ambiente e dei processi esistenti. Per questo il nostro viaggio inizia con una raffica di domande fatte al team di sviluppo, a cui chiediamo di descrivere l’architettura e il funzionamento dei suoi componenti, i flussi di dati e gli strumenti di sviluppo.
La prima esigenza emersa è stata quella di uniformare l’ambiente di sviluppo in modo che fosse utilizzabile da membri del team che lavorano su piattaforme eterogenee, sia come sistemi operativi che come IDE. Questo è stato il focus della prima fase del Cloud Native Journey, orientata a completare la containerizzazione dell’applicazione principale e a rendere l’implementazione basata sui container compatibile con le piattaforme utilizzate dal team di sviluppo. Al termine di questa fase l’ambiente basato sui container è disponibile per essere utilizzato per le attività di sviluppo e debug su diversi OS (Linux, Windows, MacOS) con diversi editor/IDE (VSCode, PhpStorm).
Terminata la prima fase, l’obiettivo si è spostato sulla realizzazione di un Proof of Concept di un vero e proprio deployment dell’applicazione basato sull’orchestrazione dei container. Questa lavorazione è stata anticipata dall’introduzione ai concetti e alle pratiche delle configurazioni dichiarative, mostrate all’opera sia per quanto riguarda l’infrastruttura, sia per l’architettura dell’applicazione.
La sfida è arrivare a validare sul campo la fattibilità, i vantaggi e gli eventuali limiti di questo tipo di soluzione. Un ulteriore elemento sfidante è costituito dalle caratteristiche specifiche dell’applicazione di AppQuality, basata su un CMS, un tipo di applicazione generalmente “monolitica” che richiede particolari attenzioni per la trasformazione cloud native.
Nel corso di questa fase sono emerse diverse necessità legate alle caratteristiche specifiche della piattaforma, che hanno fornito l’occasione di esplorare soluzioni innovative per affrontare la gestione di log distribuiti, la persistenza su file system, l’autenticazione e autorizzazione degli utenti, il networking con servizi all’interno e all’esterno di un cluster.
Nell’ultima fase infine, gli elementi visti nei segmenti precedenti sono stati inseriti nei processi di sviluppo e di gestione del codice sorgente, arricchiti dalle best practice di Continuous Integration e Continuous Delivery, per aumentare la qualità e l’affidabilità dei rilasci di software, che per AppQuality avviene a ritmi serrati, al termine di ogni sprint. In questa fase, ai task già familiari di Continuous Integration (automazione dei test e dei controlli QA), si sono aggiunte le interazioni con i componenti di un’architettura cloud native, ad esempio il container registry, e sono state proposte le diverse opzioni di delivery per gli artefatti delle pipeline, con differenti livelli di automazione possibili.
Come accennato sopra, il Cloud Native Journey inizia cercando di conoscere in modo approfondito i processi e gli strumenti utilizzati dal team di sviluppo. Il risultato di questa indagine, che continua anche durante il viaggio, quando emerge la presenza di conoscenze implicite non condivise originariamente, serve poi a modellare le tappe del viaggio, a stabilire gli obiettivi concreti di ogni fase e come raggiungerli in pratica. Questo perché il Cloud Native Journey non è semplicemente un insieme di conoscenze trasferite in modo “frontale”, ma un insieme di oggetti digitali finiti (nel senso di “done”), principalmente in forma di codice su cui il team ha già iniziato a lavorare durante il viaggio e potrà farlo anche in futuro.
Terminata la fase di assessment iniziale, si è discussa col team la modalità di interazione che fosse più funzionale rispetto a non interrompere e a non impattare sulle tempistiche delle altre attività di sviluppo in corso.
All’inizio di ogni fase sono stati condivisi gli obiettivi e i deliverable della fase stessa, in un momento di co-progettazione che ha confermato o approfondito ulteriormente i risultati dell’assessment iniziale e ha esplicitato le necessità pratiche del team rispetto alla trasformazione Cloud Native.
Per questo case i risultati non sono quantitativi se misurati al rilascio, ma coincidono con quanto è stato concretamente lasciato al team di sviluppo interno in termini di deliverables concreti.
Fase 1 (containerizzazione)
CTO, AppQuality
