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. Ogni deploy resta conservato così com'era, con il suo identificativo.

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 è il sito vero, con i dati veri, consultabile da telefono e condivisibile. 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. Se funziona nell'anteprima, funziona in produzione. È la fine del «sul mio computer andava».

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. Una chiave di produzione non finisce mai in un'anteprima.

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 esposto 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 molti dati in tempo reale che richiedono server e database sempre attivi: Netlify può ospitare il front-end, ma il backend sta altrove.
• 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.

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

Programmo dal 1999, ho consegnato più di 300 progetti e lavoro come sviluppatore esterno con circa 30 agenzie, da Roma e da remoto. Questo sito è costruito con Nuxt 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.