Provare su dati veri trova problemi che i dati di prova non troveranno mai. Mette però anche ogni nome di cliente, ogni indirizzo e ogni ordine su un server protetto con meno cura: la copia perciò si fa apposta, non con un dump nudo e crudo.

Che cosa togliere

  • I dati di pagamento e i token - anche le ultime quattro cifre.
  • Gli hash delle password, sostituiti con un valore noto così da poter entrare come chiunque.
  • Le chiavi API e i segreti dei webhook che stanno nelle tabelle delle impostazioni.
  • Tutto ciò che dovrebbe notificare se trapelasse.

Che cosa riscrivere

Gli indirizzi email, prima di tutto. Una prova che manda cento conferme d'ordine a clienti veri è di gran lunga l'incidente da staging più comune, e non si può rimediare.
UPDATE users SET
  email = CONCAT('user', id, '@example.invalid'),
  phone = NULL,
  password_hash = '$2y$10.test.hash';

A example.invalid non si può mai recapitare nulla: è riservato esattamente a questo.

Lo faccia in un solo passaggio

mysqldump --single-transaction live_db | \
  gzip > /tmp/live.sql.gz
zcat /tmp/live.sql.gz | mysql staging_db
mysql staging_db < scrub.sql   # the UPDATEs above
rm /tmp/live.sql.gz

Tenga la ripulitura come file nel repository, così chi verrà dopo farà la stessa cosa e nessuno dovrà ricordarsi l'elenco.

Poi gli URL

wp search-replace 'https://yourdomain.com' 'https://staging.yourdomain.com' --all-tables --precise

Salti ciò che non le serve

mysqldump --single-transaction --ignore-table=live_db.sessions --ignore-table=live_db.audit_log live_db

Le tabelle di log e di sessione spesso sono quasi tutta la dimensione e niente del valore.

Se i dati sono così delicati che ripulirli la mette a disagio, non li copi affatto. Generi invece un piccolo insieme realistico e lo tenga nel repository.