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.

Sono titolare del progetto indipendente descritto. Questo approfondimento si basa sulla documentazione della revisione e del rilascio.

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Illustrazione di Eddy Boscolo

L’autore

Eddy Boscolo.

Da oltre 17 anni lavoro con le infrastrutture IT. Mi occupo di architetture AWS e Azure, amministrazione Linux e automazione con Terraform, Ansible, Docker e Kubernetes, collaborando con team tecnici e responsabili di progetto.

Opero da Vicenza e offro consulenza da remoto per le aziende del Veneto.

Il prossimo passo

Devi aggiornare un servizio in produzione?

Possiamo partire dai controlli esistenti, dai passaggi di rilascio e da come recuperare in caso di problemi.