Guide Guida

Come creare un sito di staging PrestaShop

Guida per configurare un ambiente staging PrestaShop: Docker, hosting condiviso e sviluppo locale. Gli errori restano nello staging, non nel negozio.

Perché usiamo shop di staging per ogni progetto che tocchiamo

Da mypresta.rocks teniamo attivi più ambienti di staging affiancati, tra cui ps9-dev, ps8-dev, ps178-dev e ps176-dev, oltre a shop dedicati al singolo cliente quando un progetto ha bisogno del proprio clone. Non sono un lusso. Sono il modo in cui collaudiamo ogni aggiornamento di modulo, ogni upgrade di PrestaShop e ogni modifica al tema prima che un cliente li veda. Dopo un decennio passato a rilasciare moduli, non abbiamo mai incontrato un commerciante che si sia pentito di averne configurato uno, e molti che si sono pentiti di averlo saltato.

Lo schema è sempre lo stesso: un aggiornamento di modulo finisce in produzione senza collaudo, alle 9 del mattino la home page si rompe, alle 9:05 arriva il ticket di assistenza e l'ora successiva si passa a fare debug davanti a clienti reali. Uno shop di staging costa un'ora di lavoro per la costruzione e trasforma quello scenario in una correzione di 20 minuti su un URL che nessuno può vedere.

Il costo di un'ora di downtime durante i saldi supera di due ordini di grandezza il costo di mantenere un ambiente di test. Se vende su internet per vivere, ha bisogno di uno shop di staging.

Cos'è davvero uno shop di staging

È un clone completo del Suo shop di produzione (stessi file, stesso database, stesso set di moduli) servito da un URL raggiungibile solo da Lei e dal Suo team. Gli stessi percorsi di codice che colpiscono i Suoi clienti, la stessa logica di business, gli stessi casi limite. Le uniche differenze sono l'hostname, le credenziali e (se lo ha configurato come si deve) il fatto che non parte nessuna email reale e non viene addebitata nessuna carta reale.

Non è un ambiente di sviluppo per lavori da zero, e non è un backup. Abbiamo visto entrambi questi malintesi costare denaro reale ai commercianti: lo staging viene sovrascritto nel momento stesso in cui lo aggiorna, quindi qualsiasi cosa abbia costruito lì e non abbia portato in produzione va persa.

Cos'è lo staging

  • Una copia viva dei file e del database di produzione
  • Su un dominio o sottodominio separato (noi usiamo staging.yourshop.com o dev.yourshop.com)
  • Blindata dietro whitelist IP o autenticazione di base, così che entri solo il Suo team
  • Dove si provano gli aggiornamenti di modulo, le modifiche al tema e gli upgrade di PHP

Cosa non è

  • Un sandbox di sviluppo per costruire codice nuovo da zero. Quello è uno shop di sviluppo separato
  • Un backup. I backup sono immutabili. Lo staging viene cancellato a ogni aggiornamento.
  • Una cosa da impostare e dimenticare. Uno shop di staging che è da sei mesi fuori sincrono rispetto alla produzione non intercetta nulla.

Opzione 1: staging basato su Docker (quello che usiamo noi)

Tutti i nostri shop di staging girano su Docker su un'unica macchina TrueNAS. Ogni shop è uno stack docker-compose su una rete Docker condivisa, container PrestaShop, container MySQL, Redis condiviso, un bind mount per la directory html, uno per i dati MySQL. Possiamo avviare una nuova versione di PS in meno di cinque minuti, e smontarla per liberare RAM quando abbiamo finito. Una volta fatto questo, non tornerà più a "lo installo in una sottocartella di cPanel".

Prerequisiti

  • Un host Linux con almeno 2GB di RAM per ogni shop di staging (4GB se vuole che l'amministrazione risulti scattante)
  • Docker e Docker Compose installati e funzionanti
  • SSH sia verso la produzione sia verso lo staging
  • Si trova a Suo agio nel copiare e incollare comandi shell

Passo 1: il file compose

Crei una directory e un docker-compose.yml:

mkdir ~/your-shop-staging && cd ~/your-shop-staging

cat > docker-compose.yml <<'EOF'
version: '3.8'
services:
  prestashop:
    image: prestashop/prestashop:8.2
    container_name: <your-shop>
    ports:
      - "8080:80"
    environment:
      - DB_SERVER=db
      - DB_NAME=prestashop
      - DB_USER=root
      - DB_PASSWD=your_secure_password
    volumes:
      - ./html:/var/www/html
    depends_on:
      - db
    restart: unless-stopped

  db:
    image: mysql:5.7
    container_name: <your-shop>-db
    environment:
      - MYSQL_ROOT_PASSWORD=your_secure_password
      - MYSQL_DATABASE=prestashop
    volumes:
      - ./mysql:/var/lib/mysql
    restart: unless-stopped
EOF

Faccia corrispondere esattamente il tag dell'immagine PrestaShop alla versione di produzione. Se la produzione è la 1.7.8.11, usi prestashop/prestashop:1.7.8.11, non 1.7. Abbiamo visto commercianti inseguire bug fantasma per ore perché lo staging era sulla 1.7.8.10 e la produzione sulla 1.7.8.11, abbastanza simili da sembrare identici, abbastanza diversi da comportarsi in modo diverso.

Passo 2: dump della produzione

Si colleghi in SSH alla produzione ed esegua mysqldump. Usi --single-transaction su uno shop attivo, così da non bloccare la tabella degli ordini mentre i clienti stanno completando il checkout:

# Sul Suo server di produzione
mysqldump -u root -p prestashop > ~/prestashop_backup.sql

# Scarichi sulla macchina locale / sul server di staging
scp user@production-server:~/prestashop_backup.sql ./

Passo 3: import nello staging

# Avvii i container
docker compose up -d

# Attenda ~30 secondi che MySQL si inizializzi, poi importi
docker exec -i <your-shop>-db mysql -u root -pyour_secure_password prestashop < prestashop_backup.sql

Se MySQL si lamenta del set di caratteri durante l'import, imposti SET NAMES utf8mb4; in cima al file SQL. Abbiamo passato più tempo di quanto ci faccia piacere ammettere a fare debug su UTF-8 a doppia codifica sullo staging, problema che in produzione non esisteva.

Passo 4: copia dei file di produzione

# Sincronizzi i file di produzione nella directory html dello staging
rsync -avz --delete \\
  user@production-server:/var/www/html/ \\
  ./html/ \\
  --exclude='var/cache/*' \\
  --exclude='var/logs/*' \\
  --exclude='app/config/parameters.php'

Escluda sempre parameters.php da rsync. Le credenziali del DB che contiene appartengono alla produzione, se lascia che rsync le copi, il Suo shop di staging cerca di connettersi al database di produzione, che è il peggior risultato possibile del "configurare lo staging". Lo abbiamo imparato a nostre spese su un progetto cliente nel 2017 e da allora scriviamo il flag di esclusione in automatico.

Escluda anche qualsiasi directory di runtime su cui lo shop scrive in produzione. Sitemap, immagini generate di cui non ha bisogno, cartelle di backup, chiavi di licenza. rsync --delete azzera il lato di destinazione, e rsync troppo zelanti hanno cancellato sitemap generate e rotto Google Search Console più di una volta sotto i nostri occhi.

Passo 5: riscrittura degli URL e svuotamento della cache

La causa numero uno del "perché il mio shop di staging non funziona": ps_shop_url punta ancora alla produzione. La corregga:

docker exec -i <your-shop>-db mysql -u root -pyour_secure_password prestashop -e "
  UPDATE ps_shop_url SET domain='staging.yourshop.com', domain_ssl='staging.yourshop.com' WHERE id_shop=1;
  UPDATE ps_configuration SET value='staging.yourshop.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
"

Aggiorni html/app/config/parameters.php con le credenziali del DB di staging prese dal Suo file compose. Poi azzeri la cache:

docker exec <your-shop> rm -rf /var/www/html/var/cache/*

Se salta lo svuotamento della cache, i template compilati di Smarty contengono ancora l'URL di produzione e otterrà loop di redirect verso lo shop live. Su qualsiasi shop che usa OPcache (cioè qualunque cosa in produzione), riavvii PHP-FPM o richiami anche l'endpoint di reset di OPcache.

Opzione 2: sottodominio su hosting condiviso

Docker non è disponibile su cPanel, Plesk o DirectAdmin. Otterrà lo stesso risultato con un sottodominio, un secondo database e una copia dei file.

Creare il sottodominio

  1. Nel pannello di hosting, vada su Sottodomini o Domini
  2. Aggiunga staging.yourshop.com
  3. Lo faccia puntare a una nuova directory come /home/user/staging.yourshop.com

Creare un database separato

  1. Apra Database MySQL
  2. Crei qualcosa come user_staging
  3. Crei o associ un utente con tutti i privilegi su di esso

Copiare i file e importare il dump

Via SSH:

cp -r /home/user/public_html/* /home/user/staging.yourshop.com/
# Esporti la produzione
mysqldump -u user -p production_db > ~/staging_import.sql

# Importi nello staging
mysql -u user -p staging_db < ~/staging_import.sql

Modifichi app/config/parameters.php (oppure config/settings.inc.php sulla 1.6) per puntare al nuovo database, poi esegua la stessa SQL di riscrittura degli URL dell'Opzione 1, passo 5. Non dimentichi di eliminare var/cache/ dopo.

Opzione 3: sviluppo locale con XAMPP/MAMP

Va bene per il lavoro del tipo "mi consenta di controllare la schermata di amministrazione di questo modulo per dieci minuti", inutile per tutto il resto. La versione di PHP, la versione di MySQL, il modello dei permessi sui file e le estensioni a livello di sistema operativo saranno tutti diversi dal Suo server di produzione. Noi stessi usiamo stack locali, ma mai come test finale prima del deploy, qualsiasi cosa stia per toccare la produzione viene ricollaudata su uno staging basato su server che rispecchia l'ambiente di produzione.

Dopo la configurazione: le cose che La mordono se le dimentica

Blocchi subito le email in uscita

Il Suo database di staging contiene ogni indirizzo email di un cliente reale. Faccia partire un reset password, una conferma d'ordine o un cron di notifica di disponibilità, e quelle email vanno a clienti reali. Abbiamo visto commercianti scusarsi pubblicamente perché il cron del loro staging aveva mandato "il Suo ordine è stato spedito" a mille clienti reali i cui ordini, in realtà, non erano stati spediti.

Vada su Parametri avanzati → Email e poi:

  • Imposti il metodo su "Non inviare mai email": l'unica opzione del tutto sicura
  • Instradi tutto attraverso Mailtrap, così da poter comunque ispezionare le email renderizzate senza recapitarle

Disattivi i moduli di pagamento

Stripe, PayPal, Klarna, Adyen, qualsiasi cosa collegata a un account commerciante attivo. Disattivi del tutto i moduli sullo staging, oppure passi ciascuno in modalità sandbox/test. Lo stesso vale per le API di spedizione (etichette UPS, DHL, GLS) e per qualsiasi modulo che chiami un servizio esterno con effetti collaterali a pagamento.

Blocchi i motori di ricerca

Uno shop di staging indicizzato da Google è un disastro di contenuti duplicati. Tre cose da fare, con tutte le cinture allacciate:

  • Disattivi la sitemap XML in Parametri shop → Traffico & SEO
  • Inserisca un robots.txt con User-agent: * e Disallow: / nella root
  • Meglio ancora, blocchi del tutto l'accesso pubblico (sezione successiva), così che Google non lo raggiunga nemmeno

Blindi tutto dietro una whitelist IP

L'approccio più affidabile è una restrizione IP a livello di Apache o Nginx. La modalità di manutenzione può essere aggirata se l'impostazione della whitelist IP ha un bug, e l'autenticazione HTTP Basic a volte rompe i moduli con molto AJAX (l'abbiamo vista mandare in crash i nostri stessi pannelli di amministrazione quando il browser non riusciva a trasportare l'header di autenticazione attraverso XHR). La whitelist IP a livello di web server intercetta tutto prima ancora che PrestaShop venga eseguito.

Impostazioni di manutenzione PrestaShop con interruttore del negozio, campo IP di manutenzione e messaggio personalizzato

Mantenere lo staging sincronizzato con la produzione

Uno shop di staging vecchio di tre mesi è peggio di nessuno shop di staging, Le dà una falsa sicurezza. Noi aggiorniamo i nostri secondo una pianificazione e prima di ogni deploy significativo.

Quando aggiornare

  • Prima di qualsiasi modifica rilevante: aggiornamento di modulo, upgrade del core, cambio di versione PHP, rifacimento del tema
  • Almeno una volta al mese se sta sviluppando attivamente
  • Dopo ogni grande modifica del catalogo in produzione, nuovi alberi di categorie, modifiche strutturali ai prodotti, riorganizzazione di caratteristiche/attributi

Script di refresh (Docker)

#!/bin/bash
# refresh-staging.sh: Porta nello staging i dati più recenti della produzione

# 1. Dump del DB di produzione
ssh production "mysqldump -u root -p'PASS' prestashop" > /tmp/staging_refresh.sql

# 2. Import nello staging
docker exec -i <your-shop>-db mysql -u root -p'your_secure_password' prestashop < /tmp/staging_refresh.sql

# 3. Correzione degli URL
docker exec -i <your-shop>-db mysql -u root -p'your_secure_password' prestashop -e "
  UPDATE ps_shop_url SET domain='staging.yourshop.com', domain_ssl='staging.yourshop.com' WHERE id_shop=1;
  UPDATE ps_configuration SET value='staging.yourshop.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
"

# 4. Sincronizzazione dei file
rsync -avz --delete production:/var/www/html/ ./html/ --exclude='var/cache/*' --exclude='app/config/parameters.php'

# 5. Svuotamento della cache
docker exec <your-shop> rm -rf /var/www/html/var/cache/*

echo "Staging refreshed."

Gli errori che vediamo ancora commettere ai commercianti

Chiavi API di produzione lasciate al loro posto

Il numero di shop di staging che abbiamo verificato i quali stavano silenziosamente inviando addebiti Stripe reali, contattando API di spedizione reali per le etichette di tracciamento live, o consumando i limiti di frequenza delle API reali perché le chiavi erano arrivate insieme al database. Sono troppi per contarli. Ruoti ogni credenziale esterna verso una chiave di sandbox sullo staging nel momento stesso in cui il database atterra, prima ancora di aprire il pannello di amministrazione.

Cron ancora in esecuzione

Se ha impostato cron job in produzione (promemoria di carrelli abbandonati, sincronizzazione delle scorte, generazione di feed, rinnovi di licenze) controlli che il Suo pannello di hosting o i timer systemd non stiano eseguendo gli stessi job sull'hostname di staging. Avevamo un cliente il cui shop di staging mandava allegramente aggiornamenti di stock reali ad Allegro da due settimane prima che qualcuno se ne accorgesse.

Entrambi i pannelli di amministrazione aperti nello stesso browser

I cookie di amministrazione di PrestaShop sono limitati al dominio, ma i conflitti di sessione si verificano comunque quando ha entrambi gli shop autenticati nello stesso browser. Usi un browser separato, un profilo separato o una finestra in incognito per lo staging. Ogni membro del nostro team ha un profilo Firefox dedicato per gli shop di staging dei clienti.

Quando collaudare sullo staging e quando la produzione va bene

Sempre prima sullo stagingSicuro direttamente in produzione
Upgrade del core PrestaShop (1.7 → 8, 8 → 9)Modifiche ai contenuti, pagine CMS, testi prodotto
Installazioni di moduli o passaggi di versione maggioreModifiche di prezzo
Upgrade del tema o lavoro sul tema figlioAttivazione/disattivazione di moduli già collaudati
Passaggi di versione PHPAggiunta di nuovi prodotti, categorie, tag
Codice personalizzato, override, service decoratorModifiche alle regole di spedizione o fiscali
Migrazioni del database o SQL strutturaleRitocchi alle traduzioni

Vale quell'ora

La prima configurazione dello staging richiede circa un'ora. Un refresh, una volta che lo script è pronto, richiede cinque minuti. La prima volta che lo staging intercetta un aggiornamento di modulo che Le avrebbe rotto il checkout, ha recuperato l'investimento dieci volte tanto, e lo abbiamo visto accadere su shop reali che gestiamo. Docker è ciò a cui ricorreremmo se ha un VPS o una macchina dedicata; la clonazione su sottodominio è la scelta giusta sull'hosting condiviso. In ogni caso, l'obiettivo è lo stesso: niente che non sia stato collaudato tocca i Suoi clienti.

Se sta configurando lo staging proprio per collaudare i nostri moduli, il nostro programma Prova prima di acquistare Le offre una demo completa di 30 giorni di qualsiasi modulo, lo installi sullo staging, lo metta alla prova, decida prima di pagare.

Letture correlate

Moduli correlati

Domande correlate

Torna su