Un progetto indipendente · DevOps
Progetto DevOps. Test automatici e rilascio.
Aggiornare un’applicazione già utilizzata richiede controlli ripetibili, dalla riproduzione dei difetti alla verifica dopo il rilascio. Questo approfondimento riguarda lo stesso progetto indipendente raccontato nel caso Linux: una revisione successiva, documentata a settembre 2026, concentrata sui test e sulla pubblicazione delle correzioni.
Il contesto
Un’applicazione da aggiornare
Il portale era già in produzione. Una revisione aveva individuato problemi nelle anteprime dei contenuti, nella gestione delle date e nella visibilità delle pagine collegate agli account inattivi. Serviva correggere quei comportamenti mantenendo funzionanti le altre parti dell’applicazione, compresi accessi, dati esistenti e percorsi precedenti ancora supportati.
Il vincolo da rispettare
Riprodurre prima di correggere
Il primo passaggio era trasformare i difetti osservati in verifiche ripetibili. I casi problematici sono stati riprodotti su database di test prima delle correzioni. I controlli dovevano poi coprire sia i comportamenti modificati sia le autorizzazioni e i flussi collegati, senza creare contenuti di prova nella produzione.
Il rilascio, per passaggi
Dalle regressioni al rilascio
Riunire i controlli in un comando
Una procedura locale coordinava analisi del codice, controllo delle migrazioni, test applicativi e prove browser. Eseguiva anche la verifica delle dipendenze, delle procedure shell e della copertura. Dopo l’ultima correzione, la suite completa è stata rieseguita dall’inizio ed è passata.
Verificare i vincoli del database
La suite ordinaria utilizzava database temporanei. Un controllo specifico di PostgreSQL, saltato su SQLite, è stato verificato insieme ad altri test su un’istanza PostgreSQL 16 isolata. L’istanza usava un socket privato; al termine sono stati arrestati il servizio temporaneo e rimossi i dati fittizi.
Preparare una release separata
Il rilascio usava una directory versionata e un ambiente Python dedicato, con dipendenze installate verificando gli hash del lockfile. Un backup cifrato precedeva la pubblicazione. La procedura conservava le versioni precedenti e prevedeva il ritorno al codice precedente in caso di avvio o controllo di salute fallito.
Controllare dopo la pubblicazione
È stato riavviato soltanto il servizio applicativo. I confronti delle impronte aggregate prima e dopo il rilascio hanno confermato la conservazione dei dati controllati. Il collaudo pubblico ha poi verificato pagine HTTPS, layout e comportamento nei browser. Le release necessarie al recupero sono rimaste disponibili.
Il collaudo del progetto
I risultati documentati
Le misure seguenti appartengono al collaudo registrato a settembre 2026.
- Copertura documentata
- 92,7%
La suite ha raggiunto tutte le 355 funzioni applicative inventariate. La copertura descrive i percorsi verificati, non garantisce l’assenza di bug.
- Su PostgreSQL isolato
- 54 test
Superati su un’istanza temporanea separata dalla produzione, poi arrestata con rimozione dei dati fittizi.
- Confronti prima e dopo
- Rilascio verificato
Le impronte aggregate dei dati esistenti controllati coincidevano dopo la pubblicazione delle correzioni.
Il perimetro dei risultati
Cosa coprono le verifiche.
L’automazione documentata è una procedura locale di verifica. Email, autenticazione esterna e rete pubblica erano simulate nella suite deterministica; il collaudo HTTPS era separato. Le procedure di deploy e recupero venivano controllate per sintassi e salvaguardie. Il rilascio è documentato come eseguito; il ritorno automatico alla versione precedente era predisposto.
Oltre la pubblicazione
Un aggiornamento verificabile
Il risultato è un percorso ripetibile: riprodurre il problema, verificare la correzione in isolamento, pubblicare una versione identificabile e controllare il servizio. La documentazione collega ciò che è stato modificato alle prove eseguite e alle possibilità di recupero.