Deploy WordPress a downtime zero con Trellis: atomic deploy e rollback immediato

Nel mondo WordPress il deploy è spesso l’anello debole: carichi i file “sopra” quelli esistenti e, per qualche minuto, il server serve un mix di versioni vecchie e nuove. Risultato tipico: pagine che vanno in errore, classi PHP mancanti, asset non trovati, cache incoerenti. In ambienti moderni (app web, SaaS, backend) questo problema è stato risolto da anni con i cosiddetti atomic deployments (deploy atomici).

Con Trellis (il provisioning/deploy tool della famiglia Roots) questo modello è disponibile out of the box anche per WordPress: prepari una release completa in isolamento e poi “switchi” in un istante. Il sito resta raggiungibile durante tutto il processo e, se qualcosa va storto, il rollback diventa un’operazione banale.

Cosa significa davvero “zero downtime” in fase di deploy

“Zero downtime” non vuol dire che il deploy è più veloce: vuol dire che gli utenti non incontrano mai uno stato intermedio. Il codice nuovo viene assemblato in una directory separata (dipendenze incluse) e solo quando è pronto si effettua il passaggio alla nuova versione con uno switch immediato.

Il punto chiave è eliminare l’idea di “sovrascrivere file mentre il sito è online”. Sovrascrivere in-place è comodo, ma è anche la causa principale di comportamenti strani durante gli aggiornamenti: metà tema nuovo, metà tema vecchio; plugin aggiornato ma autoloader non coerente; asset compilati che non combaciano con l’HTML già in cache.

Perché il deploy “classico” di WordPress crea problemi

Nella pratica, tanti siti WordPress finiscono in produzione con uno di questi flussi:

• FTP/SFTP: upload manuale dei file modificati, sovrascrivendo quelli esistenti. È facile servire un mix di file vecchi e nuovi per diversi minuti.
• Sincronizzazione file (es. rsync): più veloce dell’FTP, ma concettualmente identico: stai comunque sovrascrivendo mentre il sito risponde.
• Deploy via plugin su host managed: spesso è comodo, ma di frequente aggiorna i file “in place” e non offre un rollback vero e immediato.

Questi approcci hanno tre difetti ricorrenti: (1) rischio reale di downtime o errori transienti, (2) rollback macchinoso quando qualcosa non va, (3) nessuna separazione netta tra fase di build/preparazione e fase di switch.

Come Trellis implementa gli atomic deploy (immutabili) con una struttura a release

Trellis adotta un modello mutuato dai deploy di applicazioni moderne: ogni deploy genera una release immutabile (i file di quella release, una volta pubblicata, non vengono più modificati). Il traffico punta sempre a un’unica “entry” stabile: un symlink chiamato current.

A livello di filesystem, su server trovi una struttura simile a questa:

/srv/www/example.com/
├── current/             # Symlink alla release attiva
├── releases/            # Tutte le release deployate
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # La più recente
├── shared/              # File condivisi tra release
│   └── uploads/
└── logs/

/srv/www/example.com/
├── current/             # Symlink alla release attiva
├── releases/            # Tutte le release deployate
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # La più recente
├── shared/              # File condivisi tra release
│   └── uploads/
└── logs/

Il web server serve sempre e solo quello che c’è dietro current. Quando arriva una nuova release, Trellis la prepara in releases/ e poi aggiorna il symlink current con un’operazione praticamente istantanea.

Cosa succede quando lanci trellis deploy production

Durante un deploy, Trellis esegue una pipeline ben definita (e personalizzabile):

• Initialize: verifica/crea la struttura e prepara una nuova directory release con timestamp.
• Update: clona il codice più recente dal repository Git in un’area separata dal sito live.
• Prepare: copia i file nella nuova directory di release.
• Build: esegue composer install per installare le dipendenze PHP.
• Share: collega (via symlink) i contenuti condivisi, ad esempio uploads, dalla directory shared alla nuova release.
• Finalize: aggiorna current per puntare alla nuova release.

Il salto tra la release precedente e quella nuova avviene senza “mescolare” file: un attimo prima stai servendo releases/20250930124530, un attimo dopo releases/20250930141622. È questo il cuore del deploy atomico.

Database: lo “zero downtime” del codice non risolve automaticamente le migrazioni

Un punto da tenere a mente: Trellis gestisce lo zero downtime sul filesystem (codice, dipendenze, struttura di release). Le modifiche di schema o trasformazioni dati nel database sono un tema separato. Nella documentazione Trellis viene chiarito che le migrazioni di database verso un nuovo schema non sono incluse automaticamente nel deploy.

Se nel tuo progetto usi Acorn (il layer application di Roots che porta pattern in stile Laravel), puoi gestire Laravel migrations anche in contesto WordPress e integrarle nel processo di rilascio. In ogni caso, il principio operativo resta: progettare migrazioni compatibili (forward/backward) quando vuoi mantenere l’assenza di interruzioni percepibili.

Rollback immediato: quando ogni release è completa e immutabile

Il vantaggio pratico più sottovalutato degli atomic deploy è il rollback. Se ogni release è una directory completa e non viene mai modificata dopo il deploy, tornare indietro significa semplicemente ripuntare current alla release precedente.

trellis rollback production

trellis rollback production

In base alla configurazione di default, Trellis mantiene sul server le cinque release più recenti. Questo ti dà un paracadute operativo molto concreto: non devi “rimettere a posto” file a mano né sperare che la cache si riallinei da sola.

Hook di deploy: personalizzare build, controlli e operazioni post-rilascio

Un altro aspetto utile è la presenza di hook (punti di estensione) per inserire task specifici in varie fasi. Tra quelli più usati:

• deploy_build_before e deploy_build_after per aggiungere step di build personalizzati.
• deploy_finalize_before e deploy_finalize_after per task subito prima/dopo lo switch della release.
• Hook per ogni fase principale: initialize, update, prepare, build, share, finalize.

Questi hook abilitano pattern molto pratici in progetti reali: backup del database prima del deploy, purge di cache applicative o CDN dopo il rilascio, notifiche al team, smoke test automatici contro la nuova release prima di considerarla “buona”.

Setup minimo: Bedrock + Trellis e primo deploy

Per partire con questo approccio, la combinazione tipica nell’ecosistema Roots è:

1. Impostare il progetto con Bedrock per una struttura WordPress più pulita e orientata a Composer.
2. Installare Trellis e configurare i parametri di deploy.
3. Configurare wordpress_sites.yml con le info del repository Git.
4. Eseguire il deploy con trellis deploy production.

Il primo deploy tende a durare di più perché inizializza la struttura e scarica tutte le dipendenze. I deploy successivi diventano più rapidi e, soprattutto, evitano quella finestra in cui il sito rischia di servire file incoerenti.

In sintesi: meno rischio operativo, più controllo

• Gli atomic deploy eliminano lo stato intermedio: niente mix di file vecchi e nuovi in produzione.
• La struttura a release con symlink current rende lo switch istantaneo e prevedibile.
• Rollback davvero immediato: basta ripuntare alla release precedente.
• Hook di deploy per inserire controlli, backup, cache purge e automazioni mirate.
• Il tema “database” resta separato: gestiscilo con attenzione (e con Acorn/migrations se rientra nel tuo stack).