Deploy WordPress: pipeline staging → produzione senza incidenti

L'aggiornamento diretto in produzione è la pratica più diffusa e più pericolosa su WordPress. Si fa perché è veloce: si cambia il file, si aggiorna il plugin, si ricarica la pagina. Funziona finché non funziona — e quando smette, il sito è giù e non si sa perché. La differenza tra un sito gestito professionalmente e uno gestito a mano non è la velocità dell'aggiornamento, è la presenza di un ambiente dove testare prima di toccare la produzione.

La pipeline minima è tre ambienti: sviluppo (locale), staging (copia della produzione, accessibile solo al team), produzione (il sito live). Ogni modifica parte dallo sviluppo, sale allo staging per il test, e solo dopo la verifica va in produzione. Il rollback è l'assicurazione: se il deploy in produzione rompe qualcosa, si torna alla versione precedente in minuti, non in ore di debug.

Git: il versioning che non si fa a mano

Il versioning a mano — copiare file, rinominare cartelle, tenere backup di backup — non scala. Git è lo standard: ogni modifica è un commit, ogni release è un tag, ogni ambiente è un branch o un checkout. Il vantaggio non è solo la storia: è la reversibilità. Un commit sbagliato si annulla con un comando, una release si torna a un tag precedente. Senza Git, il rollback è ricostruire a memoria cosa era cambiato.

# Workflow Git minimale per WordPress

# 1. Sviluppo: branch feature
git checkout -b feature/nuovo-plugin-checkout
# ... sviluppo, test locali ...
git add . && git commit -m 'Aggiunge checkout custom'

# 2. Staging: merge e deploy
git checkout staging
git merge feature/nuovo-plugin-checkout
git push origin staging
# Il deploy automatico (CI/CD) porta staging online

# 3. Produzione: solo dopo test su staging
git checkout main
git merge staging
git tag -a v1.4.0 -m 'Release: checkout custom'
git push origin main --tags
# Deploy automatico in produzione

# ROLLBACK: torna al tag precedente
git checkout v1.3.9
git push origin main --force
# Il deploy riporta la produzione a v1.3.9

Il database: il problema che Git non risolve

Git versiona i file, non il database. E il database è dove vivono i contenuti, le configurazioni dei plugin, i post. Lo staging ha un database diverso dalla produzione, e sincronizzarli è il problema classico. La pratica corretta è: lo staging ha una copia della produzione (dati reali per test reali), e le modifiche strutturali (nuovi post type, nuove opzioni) si propagano dalla produzione allo staging, non viceversa. Le modifiche al contenuto fatte in staging non vanno mai in produzione — sono test.

Per le modifiche strutturali che devono andare in produzione — nuove opzioni di configurazione, nuovi termini tassonomici — si usano script di migrazione: codice che, eseguito in produzione, applica la modifica al database. È il pattern delle migrazioni dei framework, adattato a WordPress. Lo snippet seguente è un esempio di come registrare un'opzione solo se non esiste, idempotente.

// Script di migrazione: registra un'opzione in produzione
// Da eseguire una volta dopo il deploy (es. via WP-CLI)

// wp eval-file migrazioni/001-opzione-checkout.php

if ( ! get_option( 'woo_checkout_custom_layout' ) ) {
    add_option( 'woo_checkout_custom_layout', [
        'layout'      => 'two-column',
        'show_summary' => true,
    ] );
    WP_CLI::success( 'Opzione checkout registrata' );
} else {
    WP_CLI::success( 'Opzione checkout già presente, skip' );
}

# Esecuzione: wp eval-file migrazioni/001-opzione-checkout.php
# Idempotente: se eseguito due volte, non fa danni.

Il rollback: l'assicurazione che si testa

Un rollback non testato è un'ipotesi, non un'assicurazione. La pipeline seria include un test del rollback: dopo un deploy, si simula un rollback in un ambiente di test per verificare che torni alla versione precedente senza errori. Se il rollback non funziona in test, non funzionerà in produzione quando servirà davvero — e quel momento è il peggiore per scoprirlo.

'Funziona sul mio computer' non è una strategia di deploy. La pipeline staging → test → produzione con Git, ambienti separati e rollback testato è il modo professionale di gestire un sito WordPress che non può permettersi di stare giù. Lo sviluppo personalizzato include la configurazione di questa pipeline quando il sito lo richiede: non è lusso, è la differenza tra un incidente gestito in minuti e uno gestito in ore. Un check-up dell'infrastruttura include la verifica della pipeline di deploy e della testabilità del rollback.