Testing e CI/CD per WordPress: pipeline automatizzate per non rompere il sito in produzione

La maggior parte dei siti WordPress si aggiorna così: si clicca 'aggiorna' in produzione, si incrocia le dita, e se qualcosa si rompe si piange. È il metodo più comune e il più pericoloso. Un aggiornamento del core, di un plugin o di un tema può rompere il sito in modi che non prevedi — un conflitto di versione PHP, una funzione deprecata, un cambio di API. Senza una pipeline di test e deploy, ogni aggiornamento è una scommessa. Con una pipeline, è un'operazione ripetibile e sicura.

Il punto che quasi tutti sbagliano è pensare che CI/CD sia roba da team DevOps con infrastruttura complessa. Non lo è. Una pipeline WordPress base ha tre componenti: un ambiente di staging (una copia del sito dove testi), un sistema di versioning (Git), e un meccanismo di deploy automatico dal repository al server. Se hai queste tre cose, hai una pipeline. Se ne manca una, stai aggiornando alla cieca.

L'ambiente di staging: non opzionale, obbligatorio

Lo staging è una copia del sito in produzione, su un dominio separato (es. staging.example.com), dove testi gli aggiornamenti prima di rilasciarli. Su hosting gestito, lo staging è spesso incluso — WP Planet lo offre su tutti i piani Managed e Business. Se il tuo hosting non lo offre, crea un sottodominio con una copia del database e dei file. Lo staging non è un lusso — è la differenza tra 'l'aggiornamento ha rotto il checkout e l'ho scoperto dai clienti' e 'l'aggiornamento ha rotto il checkout e l'ho scoperto in staging prima di toccare produzione'.

Il deploy automatizzato con Git

Il deploy manuale (FTP, copia file, preghiera) è il modo più comune e più sbagliato di aggiornare un sito. Il deploy automatizzato con Git è la base di una pipeline CI/CD. Il concetto: il codice del tema e dei plugin custom vive in un repository Git; ogni push sul branch main (o production) triggera un deploy automatico sul server. Il deploy copia i file, svuota la cache, e notifica il team.

Un deploy script base con WP-CLI e rsync:

#!/bin/bash
# deploy.sh — deploy da Git a produzione via SSH
set -e

PRODUCTION_HOST="www.example.com"
PRODUCTION_PATH="/var/www/html"
STAGING_HOST="staging.example.com"
STAGING_PATH="/var/www/staging"

BRANCH="${1:-main}"

# 1. Deploy su staging prima (sempre)
echo "→ Deploy su staging..."
rsync -avz --delete \
  --exclude='.git' \
  --exclude='node_modules' \
  --exclude='.env' \
  --exclude='wp-config.php' \
  ./ "${STAGING_HOST}:${STAGING_PATH}/wp-content/themes/wp-planet/"

# 2. Test su staging (verifica che il sito risponda)
STAGING_STATUS=$(curl -o /dev/null -s -w '%{http_code}' "https://${STAGING_HOST}/")
if [ "$STAGING_STATUS" != "200" ]; then
  echo "✗ Staging non risponde (HTTP $STAGING_STATUS) — deploy bloccato"
  exit 1
fi
echo "✓ Staging OK (HTTP 200)"

# 3. Se il branch è main, deploy su produzione
if [ "$BRANCH" = "main" ]; then
  echo "→ Deploy su produzione..."
  rsync -avz --delete \
    --exclude='.git' \
    --exclude='node_modules' \
    --exclude='.env' \
    --exclude='wp-config.php' \
    ./ "${PRODUCTION_HOST}:${PRODUCTION_PATH}/wp-content/themes/wp-planet/"

  # Svuota la cache di produzione
  ssh "$PRODUCTION_HOST" "wp cache flush --path=$PRODUCTION_PATH --allow-root 2>/dev/null || true"
  echo "✓ Produzione aggiornata e cache svuotata"
fi

I test automatizzati: non servono mille, ne bastano tre

I test automatizzati non devono essere completi — devono coprire i casi critici. Tre test bastano per la maggior parte dei siti WordPress: test che il sito risponde (200), test che il checkout funziona (aggiungi al carrello, completa), e test che le pagine principali non danno 404. Non sono test unitari — sono test di smoke, e sono quelli che ti salvano quando un aggiornamento rompe qualcosa di evidente.

#!/bin/bash
# smoke-tests.sh — test di base dopo ogni deploy
SITE_URL="https://www.example.com"
FAIL=0

# Test 1: le pagine principali rispondono 200
for path in "/" "/chi-siamo" "/servizi" "/contatti" "/magazine"; do
  STATUS=$(curl -o /dev/null -s -w '%{http_code}' "${SITE_URL}${path}")
  if [ "$STATUS" != "200" ]; then
    echo "✗ $path → HTTP $STATUS"
    FAIL=1
  else
    echo "✓ $path → 200"
  fi
done

# Test 2: il sitemap.xml è accessibile
SITEMAP_STATUS=$(curl -o /dev/null -s -w '%{http_code}' "${SITE_URL}/sitemap.xml")
if [ "$SITEMAP_STATUS" != "200" ]; then
  echo "✗ sitemap.xml → HTTP $SITEMAP_STATUS"
  FAIL=1
else
  echo "✓ sitemap.xml → 200"
fi

# Test 3: il feed RSS è accessibile
FEED_STATUS=$(curl -o /dev/null -s -w '%{http_code}' "${SITE_URL}/feed.xml")
if [ "$FEED_STATUS" != "200" ]; then
  echo "✗ feed.xml → HTTP $FEED_STATUS"
  FAIL=1
else
  echo "✓ feed.xml → 200"
fi

if [ "$FAIL" = "1" ]; then
  echo "\n✗ Test falliti — rollback consigliato"
  exit 1
else
  echo "\n✓ Tutti i test OK"
  exit 0
fi

Il rollback: la rete di sicurezza che quasi nessuno ha

Il rollback è la capacità di tornare alla versione precedente in secondi, non in ore. Senza rollback, un deploy che rompe il sito significa ore di downtime mentre ripristini manualmente. Con rollback, significa un comando e trenta secondi. Il rollback più semplice su hosting gestito è un backup del tema precedente che il deploy script crea prima di sovrascrivere:

# Nel deploy script, prima di sovrascrivere il tema:
BACKUP_DIR="/var/www/backups/themes/$(date +%Y%m%d_%H%M%S)"
ssh "$PRODUCTION_HOST" "mkdir -p $BACKUP_DIR && cp -r $PRODUCTION_PATH/wp-content/themes/wp-planet/ $BACKUP_DIR/"

# In caso di fallimento dei test, rollback:
# ssh "$PRODUCTION_HOST" "rm -rf $PRODUCTION_PATH/wp-content/themes/wp-planet/ && cp -r $BACKUP_DIR/wp-planet/ $PRODUCTION_PATH/wp-content/themes/"
# ssh "$PRODUCTION_HOST" "wp cache flush --path=$PRODUCTION_PATH --allow-root"

# Verifica dopo il rollback
ROLLBACK_STATUS=$(curl -o /dev/null -s -w '%{http_code}' "https://www.example.com/")
if [ "$ROLLBACK_STATUS" = "200" ]; then
  echo "✓ Rollback completato — sito ripristinato"
else
  echo "✗✗ CRITICO: rollback fallito — intervento manuale necessario"
fi

Una pipeline CI/CD non è un lusso da team grandi — è la base della gestione professionale di un sito WordPress. Aggiornare in produzione senza staging, senza test, senza rollback, è gestire un sito alla mercé del caso. La pipeline non previene tutti i problemi — ma trasforma ogni problema da un'emergenza con ore di downtime a un inconveniente con minuti di recupero. E nel mondo del web, la differenza tra ore e minuti è la differenza tra un cliente perso e un cliente che non se ne accorge neanche.