Convierta una base de datos de producción en datos de prueba

Cuanto más cerca esté una prueba de la producción, mejor puede emular el comportamiento de producción. Me gustaría copiar las copias de seguridad de la base de datos de la producción en nuestros entornos de prueba, pero ¿qué necesito cambiar para que la prueba funcione y evitar interferir con la producción o enviar por correo electrónico accidentalmente a clientes reales (además de configurar web/%secure/base_urlcon la URL de prueba)?

Otra forma de pensar sobre esta pregunta sería considerar cómo generar algo como Magento Sample Data a partir de mis propios datos de producción.

1) Volcado de DB

Cuando realiza la exportación, solo puede exportar la estructura de las siguientes tablas:

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

También core_url_rewritese puede importar solo con la estructura y ejecutar una URL de catálogo Reescribe reindexar después de la importación, a menos que necesite todos esos registros (para varias pruebas).

También puede limpiar los carros abandonados (pista:) sales_flat_quote, también puede eliminar pedidos si no los necesita y mantener un número limitado

2) Configuraciones de configuración

• web / (no seguro | seguro) / base_url
• direcciones de correo electrónico de contacto
• deshabilite el correo electrónico ( system/smtp/disable) para que no envíe correos electrónicos por error

3) Anonimizar la información del cliente

• puedes usar el módulo Anonygento para Magento
• escriba su propio guión para ofuscar la información del cliente / pedidos de venta / etc.

4) Configuración del módulo

• puede habilitar el modo sandbox para los módulos de pago / envío y realizar la configuración adecuada
• compruebe los módulos utilizados para diversas integraciones (ya sea deshabilitarlos o configurarlos en modo sandbox)

Escribimos un script para manejar los volcados de DB para ramificar. Lee este artículo .

El principio básico es que lee local.xmlpara obtener las credenciales de la base de datos, luego volca los datos sobre esa base. Divide el volcado en dos partes, solo la estructura y luego los datos. Pero la clave es que acelera el proceso de volcado convencional al omitir datos no esenciales y evita de manera crítica cualquier bloqueo de tabla durante el volcado que de otro modo bloquearía / colgaría su sitio en vivo.

Cuando tenga el volcado de MySQL, puede cambiar la URL muy fácilmente simplemente usando sed

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

Luego ejecute una importación mysql en su nueva base de datos.

Entonces, sin el script, una versión muy básica se vería así.

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

No hay ninguna razón para tener que eliminar el archivo local.xml o volver a ejecutar el instalador si cambia las URL en la base de datos de esta manera.

Todo el proceso de ramificación está bien cubierto en nuestra Guía Magento GIT . Este es un buen proceso para crear ramas de desarrollo, pero reduce el DB en vivo por un margen significativo. Por lo tanto, las pruebas no serán completamente las mismas que en el sitio en vivo.

Por lo tanto, realizar un volcado de DB de vainilla, reemplazar sed, importar DB es suficiente para un sitio de preparación. Y reflejará / coincidirá el sitio en vivo lo más cerca posible.

En términos de evitar las comunicaciones con los clientes, nunca lo hemos considerado una necesidad, ya que siempre creamos cuentas deliberadamente para las pruebas, nunca utilizamos pedidos reales de los clientes para las pruebas.

Una opción para el problema del correo electrónico es configurar su sitio de desarrollo para redirigir TODOS los correos electrónicos hacia usted. Añade un poco de tranquilidad.

La forma en que lo haga depende de su entorno; para nosotros, agregar esto al servidor virtual hace el trabajo:

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

Nada. Cambiar las URL seguras y no seguras es suficiente.

También puede omitir log_*datos de tablas solo para hacer que su volcado sea más ligero.

Pruebe esto, codificará los correos electrónicos de los usuarios para ayudarlo con su problema al enviar accidentalmente clientes en vivo desde el entorno de prueba

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