Tester sur des données réelles révèle des problèmes que des données de test ne révéleront jamais. Cela pose aussi chaque nom de client, chaque adresse et chaque commande sur un serveur protégé avec moins de soin : la copie se fait donc délibérément, pas avec un export brut.

Ce qu'il faut retirer

  • Les données de paiement et les jetons - même les quatre derniers chiffres.
  • Les empreintes de mots de passe, remplacées par une valeur connue pour pouvoir se connecter sous n'importe quel compte.
  • Les clés d'API et les secrets de webhooks rangés dans les tables de réglages.
  • Tout ce que vous devriez déclarer en cas de fuite.

Ce qu'il faut réécrire

Les adresses e-mail avant tout. Un test qui envoie cent confirmations de commande à de vrais clients est de loin l'accident de préproduction le plus fréquent, et il est irrattrapable.
UPDATE users SET
  email = CONCAT('user', id, '@example.invalid'),
  phone = NULL,
  password_hash = '$2y$10.test.hash';

On ne peut jamais rien livrer à example.invalid : ce domaine est réservé exactement pour cela.

Le faire en une seule passe

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

Gardez le nettoyage sous forme de fichier dans le dépôt, pour que la personne suivante fasse la même chose et que personne n'ait à mémoriser la liste.

Puis les URL

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

Sautez ce dont vous n'avez pas besoin

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

Les tables de journaux et de sessions font souvent l'essentiel du volume et rien de la valeur.

Si les données sont assez sensibles pour que le nettoyage vous inquiète, ne les copiez pas. Générez plutôt un petit jeu réaliste et gardez-le dans le dépôt.