Convertir une base de données de production en données de test

Plus un test est proche de la production, mieux il peut émuler le comportement de production. Je voudrais copier les sauvegardes de la base de données de la production dans nos environnements de test, mais que dois-je changer pour que le test fonctionne, et pour éviter d'interférer avec la production ou d'envoyer des e-mails accidentels à de vrais clients (en plus de définir web/%secure/base_urlavec l'URL de test)?

Une autre façon de réfléchir à cette question serait de réfléchir à la manière de générer quelque chose comme Magento Sample Data à partir de mes propres données de production.

1) DB Dump

Lorsque vous effectuez l'exportation, vous ne pouvez exporter que la structure des tableaux suivants:

core_cache
core_cache_option
core_cache_tag
log_customer
log_quote
log_summary
log_summary_type
log_url
log_url_info
log_visitor
log_visitor_info
log_visitor_online
enterprise_logging_event
enterprise_logging_event_changes
index_event
index_process_event
report_event
report_viewed_product_index
dataflow_batch_export
dataflow_batch_import

Vous core_url_rewritepouvez également être importé uniquement avec la structure et exécuter une réindexation de l'URL du catalogue de réécriture après l'importation, sauf si vous avez besoin de tous ces enregistrements (pour divers tests).

Vous pouvez également nettoyer les chariots abandonnés (indice:) sales_flat_quote, vous pouvez également supprimer les commandes si vous n'en avez pas besoin et en garder un nombre limité

2) Paramètres de configuration

• web / (non sécurisé | sécurisé) / base_url
• adresses e-mail de contact
• désactiver l'email ( system/smtp/disable) pour ne pas envoyer d'emails par erreur

3) Anonimisez les informations client

• vous pouvez utiliser le module Anonygento pour Magento
• rédigez votre propre script pour masquer les informations client / les commandes client / etc.

4) Paramètres du module

• vous pouvez activer le mode sandbox pour les modules de paiement / expédition et effectuer les réglages appropriés
• vérifier les modules utilisés pour diverses intégrations (les désactiver ou les mettre en mode sandbox)

Nous avons écrit un script pour gérer les vidages DB pour les branchements. Lisez cet article .

Le principe de base est qu'il lit le local.xmlpour récupérer les informations d'identification de la base de données, puis vide les données sur cette base. Il divise le vidage en deux parties, la structure uniquement, puis les données. Mais la clé est qu'elle accélère le processus de vidage conventionnel en ignorant les données non essentielles , et surtout empêche tout verrouillage de table pendant le vidage qui bloquerait / bloquerait autrement votre site en direct.

Lorsque vous avez le vidage MySQL, vous pouvez modifier l'URL très facilement simplement en utilisant sed

sed -i 's/www.mydomain.com/staging.mydomain.com/g' ./var/db.sql

Exécutez ensuite une importation mysql dans votre nouvelle base de données.

Donc sans le script, une version très basique ressemblerait à ceci.

mysqldump -hHostname -uUsername LiveDbname -p > db.sql
sed -i 's/www.mydomain.com/staging.mydomain.com/g' db.sql
mysql -hHostname -uUsername DevDbname -p < db.sql

Il n'y a aucune raison de devoir supprimer le fichier local.xml ou de réexécuter le programme d'installation si vous modifiez les URL dans la base de données de cette manière.

L'ensemble du processus de branchement est bien couvert dans notre guide Magento GIT . C'est un bon processus pour créer des branches de développement, mais réduit la base de données en direct d'une marge significative. Les tests ne seront donc pas complètement les mêmes que sur le site en direct.

Donc, effectuer un vidage DB vanille, remplacer sed, l'importation DB est suffisante pour un site intermédiaire. Et reflétera / fera correspondre le site en direct aussi étroitement que possible.

En termes d'empêcher les communications avec les clients - nous n'avons jamais trouvé cela nécessaire, car nous créons toujours des comptes délibérément pour les tests, sans jamais utiliser de vraies commandes client pour les tests.

Une option pour le problème des e-mails consiste à configurer votre site de développement pour rediriger TOUS les e-mails vers vous. Ajoute un peu d'esprit.

La façon dont vous procédez dépend de votre environnement - pour nous, l'ajout au vhost fait le travail:

php_admin_value sendmail_path "/usr/sbin/sendmail -i -- [email protected],[email protected]"

Rien. Changer des URL sécurisées et non sécurisées est tout à fait suffisant.

Vous voudrez peut-être également omettre les log_*données des tables juste pour alléger votre vidage.

Essayez ceci, il brouillera les e-mails des utilisateurs pour vous aider à résoudre votre problème en envoyant par e-mail des clients en direct à partir de l'environnement de test

UPDATE customer_entity SET email = REPLACE(email, '@', '-test@abcxyz123-')