Pubblicare un sito con GitHub e Netlify: deploy atomici, anteprime e il flusso che uso ogni giorno

Per anni pubblicare un sito ha significato trascinare file su un server via FTP e sperare di non sovrascrivere quello sbagliato. Oggi tutti i miei progetti nuovi passano da GitHub e Netlify, compreso questo sito. Non è una scelta di moda: è il flusso che mi permette di lavorare in modo più sicuro, verificabile e veloce, e di far vedere ogni modifica al cliente o all'agenzia prima che vada online.

Il flusso, in sintesi

Il codice (e spesso i contenuti, in Markdown) vive in un repository su GitHub. Netlify è collegato al repository: a ogni push esegue la build in un ambiente pulito e pubblica il risultato sulla sua CDN. Ogni pull request genera un Deploy Preview, un indirizzo di prova separato con il sito completo e funzionante. Quando la modifica è approvata e unita al ramo principale, parte il deploy di produzione.

Cosa cambia tecnicamente

Deploy atomici e immutabili

Con l'FTP il sito passa per uno stato intermedio mentre i file si caricano: metà vecchio, metà nuovo. Su Netlify la nuova versione viene costruita per intero e attivata in un unico passaggio: i visitatori vedono la versione precedente o quella nuova, mai un ibrido. I deploy conservati mantengono un riferimento alla versione pubblicata. La disponibilità storica dipende dalle regole di conservazione del piano.

Rollback istantanei

Siccome i deploy sono immutabili, tornare indietro non richiede di ricostruire nulla: si riattiva quello precedente. In parallelo, ogni modifica ha un commit su GitHub che si può annullare con un revert e ripubblicare.

Anteprima per ogni modifica

È il vantaggio più evidente per chi commissiona il lavoro. Il Deploy Preview permette di verificare la versione proposta su un indirizzo separato, da telefono e da desktop. Uso dati di test o minimizzati e accessi separati; quando necessario proteggo l’anteprima dall’accesso pubblico. L'agenzia o il cliente approvano sul prodotto, non su screenshot.

Build riproducibili

La build gira in un ambiente pulito con versioni di Node e dipendenze bloccate dal file di lock. Questo riduce le differenze tra ambienti, ma non le elimina: variabili, dati, domini, servizi esterni e permessi devono essere verificati anche nel contesto di produzione.

Configurazione nel codice

Redirect, header di sicurezza e di cache, regole per contesto di deploy stanno in file del progetto, versionati e revisionati come il resto. Nessun pannello che qualcuno modifica a mano senza lasciare traccia. Le variabili d'ambiente si separano per contesto: produzione, anteprime, rami. La separazione va configurata esplicitamente: le variabili possono avere lo stesso valore in tutti i contesti per impostazione predefinita. Le chiavi riservate restano lato server e alle anteprime assegno credenziali di test con i soli permessi necessari.

Funzioni serverless e moduli

Le parti dinamiche si scrivono come funzioni serverless, eseguite solo quando servono: la chat AI di questo sito, per esempio, è una route server che legge la base di conoscenza e chiama l'API del modello, con la chiave che non arriva mai al browser. I moduli di contatto passano da Netlify Forms, senza un server da mantenere. HTTPS si attiva e si rinnova da solo.

Superficie d'attacco ridotta

Un sito generato in anticipo non ha un database necessario al funzionamento dell’applicazione né un pannello di login pubblico. Restano da proteggere gli account di GitHub, di Netlify e del registrar del dominio, con autenticazione a due fattori. Il confronto con WordPress è in Sito WordPress hackerato.

Il mio flusso di lavoro

È lo stesso che applico a questo sito:

1. un ramo per ogni tema di lavoro, con un nome che dice cosa contiene;
2. commit piccoli e descritti;
3. pull request su GitHub, con il Deploy Preview generato da Netlify;
4. verifica sull'anteprima, insieme a chi deve approvare;
5. merge sul ramo principale, che non si tocca mai direttamente, e deploy di produzione automatico.

Così ogni modifica ha una storia, un'anteprima e una via di ritorno.

Dominio, DNS e posta

Due raccomandazioni che vedo trascurare spesso. Il dominio deve essere intestato al titolare del sito, con rinnovo automatico e accesso al registrar sotto il suo controllo. La posta resta su un servizio dedicato, separato dall'hosting del sito, con SPF, DKIM e DMARC configurati: spostare il sito su Netlify non deve toccare le email, e i record DNS vanno cambiati con questo in mente.

Quando non è la soluzione giusta

• Redazioni numerose non tecniche senza un CMS headless collegato: Git non è uno strumento di scrittura per tutti.
• Applicazioni con requisiti particolari di esecuzione o connessioni persistenti: valuto i limiti delle funzioni e i servizi gestiti disponibili; alcune componenti del backend possono richiedere un’infrastruttura diversa.
• E-commerce complessi su WooCommerce che funzionano bene: spostarli ha un costo che raramente si ripaga.
• Siti che vanno già bene su un hosting tradizionale, veloci, sicuri e aggiornati.

I limiti del rollback

Ripubblicare un deploy precedente ripristina gli artefatti disponibili di quella versione; non ripristina automaticamente database, servizi esterni o dati modificati dagli utenti. Una migrazione incompatibile può quindi rendere inutilizzabile il vecchio codice anche dopo un rollback riuscito.

Per modifiche al modello dati uso passaggi compatibili: prima aggiungo il nuovo campo o schema mantenendo quello precedente, poi migro i dati e aggiorno i lettori, infine rimuovo ciò che non serve più dopo il periodo di verifica. Prima del rilascio controllo quali deploy sono ancora disponibili e come sospendere nuove pubblicazioni automatiche mentre gestisco il ripristino.

L’anteprima usa valori e servizi di test assegnati esplicitamente al suo contesto; il solo indirizzo separato non isola dati e segreti.

Riferimenti: gestione e rollback dei deploy, variabili d’ambiente.

Come la vedo io

Da quando lavoro così non tornerei indietro. La differenza non è solo tecnica: cambia il rapporto con chi commissiona il lavoro. Invece di «ho caricato, controlla», mando un link di anteprima e il sito vero da guardare. Invece di «speriamo che l'aggiornamento non rompa nulla», c'è un deploy che si annulla con un clic. È anche il motivo per cui, quando un progetto non ha bisogno di un pannello dinamico, propongo di passare da WordPress a Nuxt.js e di pubblicare in questo modo.

C'è anche un aspetto di trasparenza che i clienti apprezzano: la cronologia del repository è un registro leggibile di tutto ciò che è stato fatto, con date e descrizioni. Non serve fidarsi di un resoconto: il lavoro è lì, verificabile, e resta di proprietà del cliente anche se un giorno sceglierà un altro sviluppatore.

Perché affidarlo a me

Pubblico siti da anni: dal 1999 ho consegnato più di 300 progetti e collaboro con più di 30 agenzie, da Roma e da remoto. Questo sito è costruito con Nuxt.js e pubblicato con GitHub e Netlify: imposto lo stesso flusso, con anteprime, redirect e variabili per contesto, e lo lascio documentato a te o alla tua agenzia.

Se vuoi capire se questo modo di pubblicare è adatto al tuo sito, scrivimi: in una chiacchierata di circa 20 minuti guardiamo come pubblichi oggi. Il servizio è in Hosting e infrastruttura.