Deploy automatico: come pubblicare senza intervento manuale

Pubblicare a mano funziona finché non funziona: prima o poi qualcuno salta un passaggio, carica il file sbagliato o dimentica di eseguire una migrazione — di solito il venerdì pomeriggio. Il deploy automatico elimina quella categoria di errori, ma va impostato sapendo cosa serve prima e come si torna indietro. In questo articolo trovi entrambe le cose.

Se stai cercando dove pubblicare un sito e come funzionano le piattaforme, il punto di partenza è come fare il deploy di un sito. Qui si parla di come rendere quel processo automatico e affidabile.

Cos'è

Il deploy automatico è il processo per cui, integrando del codice, la nuova versione va online da sola: costruzione, verifica e pubblicazione avvengono senza intervento manuale.

È la parte "CD" del CI/CD, e vale la pena distinguere due livelli:

• Continuous delivery — ogni modifica è pronta per andare online, ma la pubblicazione la decide una persona premendo un pulsante
• Continuous deployment — va online da sola, senza approvazione

La differenza pratica è il livello di fiducia nei test. La prima è la scelta prudente e va benissimo per la maggior parte dei progetti; la seconda richiede una verifica automatica di cui ti fidi davvero.

Cosa serve prima di automatizzare

Qui sta il consiglio che conta più di tutta la configurazione.

Automatizzare un processo che non funziona significa sbagliare più in fretta. Prima di rendere automatico il deploy, servono tre cose:

1. Test automatici affidabili. Sono l'unica rete di sicurezza. Senza, stai automatizzando la pubblicazione di problemi. E se i test sono instabili — falliscono a caso una volta su cinque — è peggio che non averli: il team impara a rilanciarli senza guardare, e quando il fallimento è vero nessuno se ne accorge.

2. Un ambiente di prova. Una copia del sistema dove verificare prima della produzione.

3. Un modo per tornare indietro. Ci arrivo tra poco, ma va deciso prima del primo rilascio automatico, non dopo il primo incidente.

Come è fatto

Il flusso tipico, indipendentemente dagli strumenti:

1. Invii il codice su un ramo
2. I controlli automatici partono — test, linter, build
3. Se passano, l'artefatto viene costruito
4. Va in ambiente di prova, automaticamente
5. Verifiche sull'ambiente di prova (test di integrazione, controlli di raggiungibilità)
6. Va in produzione — automaticamente o su approvazione
7. Verifica post-rilascio che il sistema risponda
8. Notifica dell'esito

Su GitHub questo si costruisce con le Actions, su GitLab con le pipeline. Su piattaforme come Vercel, Netlify o Cloudflare gran parte è già preconfigurata: colleghi il repository e i punti 1-4 avvengono da soli.

Le strategie di rilascio

Come la nuova versione sostituisce la vecchia. Non è un dettaglio: determina cosa succede agli utenti nel momento del cambio.

Sostituzione diretta. Si spegne la vecchia, si accende la nuova. Semplice, con una finestra di indisponibilità. Accettabile su progetti piccoli e in orari di basso traffico.

Rilascio progressivo. Le istanze vengono sostituite una alla volta. Nessuna interruzione, ma per un periodo convivono due versioni — il che richiede che siano compatibili tra loro.

Ambiente parallelo. Si prepara l'intera nuova versione accanto a quella attiva, si verifica, e si sposta il traffico in blocco. Il vantaggio è il ritorno indietro immediato: si rimanda il traffico all'ambiente precedente, che è ancora lì.

Rilascio graduale. La nuova versione riceve prima una piccola percentuale di traffico, che aumenta se non emergono problemi. È la strategia più sicura e quella che permette di accorgersi di un problema prima che colpisca tutti.

Per un progetto piccolo, la sostituzione diretta va benissimo. Le altre servono quando l'indisponibilità ha un costo reale.

Il ritorno indietro

È la parte che nessuno prepara e che serve sempre.

La domanda da farsi prima del primo rilascio automatico è: quanto ci metto a tornare alla versione precedente? Se la risposta è "non lo so", il deploy automatico è prematuro.

Le opzioni:

Ripubblicare il commit precedente. Semplice, ma richiede di rifare tutto il processo — minuti, non secondi.

Tenere l'ambiente precedente pronto. Immediato, ma costa risorse.

Annullare la modifica con un revert e lasciare che la pipeline ripubblichi — vedi git reset vs revert.

La complicazione vera sono i database. Il codice torna indietro in un istante; una migrazione applicata al database no. Il criterio che risolve: le migrazioni devono essere retrocompatibili. Aggiungi una colonna, non rinominarla; scrivi su entrambe le versioni per un ciclo, e rimuovi la vecchia solo dopo. È laborioso e ti salva quando serve.

Gli errori tipici

Automatizzare senza test. Già detto, ed è il primo per gravità.

I segreti nel file di configurazione. Vanno nelle impostazioni del repository o in un gestore dedicato. Un segreto committato resta nella storia anche se lo rimuovi dopo, e va considerato compromesso.

Nessuna notifica sui fallimenti. Un rilascio fallito in silenzio si scopre da un cliente.

Nessuna verifica dopo la pubblicazione. Il processo dice "riuscito" ma il sito non risponde. Un controllo automatico di raggiungibilità sull'endpoint di stato chiude questo buco.

Rilasciare il venerdì sera. Non è superstizione: è che se qualcosa si rompe, non c'è nessuno per sistemarlo.

Confondere ambiente di prova e produzione. Configurazioni sbagliate, migrazioni eseguite sul database sbagliato. Vanno separati in modo che sia difficile confonderli.

Processi lentissimi. Se il rilascio richiede quaranta minuti, si rilascia meno spesso, e ogni rilascio contiene più cambiamenti — quindi più rischio. La velocità della pipeline influisce direttamente sulla sicurezza dei rilasci.

Da dove partire

Se non hai nulla di automatizzato, la progressione sensata:

1. Test automatici a ogni proposta di modifica. Prima di tutto il resto.

2. Deploy automatico verso l'ambiente di prova. Nessun rischio, e prendi confidenza con il processo.

3. Deploy in produzione con approvazione manuale. Un pulsante da premere: hai l'automazione senza rinunciare al controllo.

4. Deploy completamente automatico, solo quando ti fidi davvero dei test.

Molti team si fermano al punto 3, ed è una scelta perfettamente ragionevole. Il beneficio grosso — eliminare gli errori manuali e la ripetibilità — si ottiene già lì.

In sintesi

Il deploy automatico elimina la categoria di errori legata ai passaggi manuali dimenticati. Ma prima di automatizzare servono test affidabili, un ambiente di prova e un modo per tornare indietro — quest'ultimo deciso prima del primo rilascio, non dopo il primo incidente.

Le strategie di rilascio si distinguono per cosa succede agli utenti durante il cambio: la sostituzione diretta basta per progetti piccoli, il rilascio graduale è il più sicuro.

La complicazione che sorprende sempre sono le migrazioni del database: il codice torna indietro subito, i dati no. Il rimedio è renderle retrocompatibili.

E la progressione da seguire: test automatici, poi deploy automatico sull'ambiente di prova, poi produzione con approvazione manuale. Fermarsi lì è una scelta legittima — il beneficio principale si è già ottenuto.