Ogni modifica fatta direttamente su un sito in produzione è una modifica provata sui suoi clienti. Una copia di staging costa un sottodominio e toglie di mezzo tutto questo - purché tre cose siano a posto, perché un sito di staging trascurato fa danni veri.
1. Lo tenga fuori dai risultati di ricerca
Una copia di staging indicizzata da Google fa concorrenza al sito vero sui contenuti del sito vero, e i clienti atterrano su una pagina a metà. La blocchi prima che esista, non dopo.
# nginx, on the staging server block only
add_header X-Robots-Tag "noindex, nofollow" always;Lo protegga anche con una password: è l'unico metodo che impedisce pure che un link venga condiviso per sbaglio.
2. Gli impedisca di mandare posta
Una copia di staging con una tabella ordini vera scriverà a clienti veri a proposito di ordini di prova. Punti la posta su un raccoglitore, oppure disattivi del tutto l'invio.
# WordPress: a tiny must-use plugin
add_filter('pre_wp_mail', '__return_false');3. Punti i pagamenti sulla sandbox
Chiavi di test, sempre. Un sito di staging con chiavi di pagamento reali preleverà denaro vero da una carta vera durante una prova.
La messa online
- Prima faccia il backup del sito in produzione — File e database. Questo è il pulsante annulla.
- Porti i file, non il database, se i contenuti sono cambiati in produzione — Altrimenti sovrascrive ordini e commenti arrivati dopo la copia.
- Porti il database solo se in produzione i contenuti NON sono cambiati — Poi cerchi e sostituisca l'URL dello staging con quello di produzione.
- Svuoti ogni cache — Applicazione, server e CDN. Una cache di pagina servirebbe il vecchio sito per ore.
- Percorra il cammino critico — Accedere, mettere nel carrello, pagare, ricevere la mail.
wp search-replace 'https://staging.yourdomain.com' 'https://yourdomain.com' --all-tablesNon porti mai il database sopra un negozio in attività. Distribuisca il codice, e faccia le modifiche ai contenuti in produzione. In quale direzione viaggia ciascun tipo di modifica: è tutta lì la disciplina.
