Преобразование производственной базы данных в тестовые данные

Чем ближе тест к производству, тем лучше он может имитировать поведение производства. Я хотел бы скопировать резервные копии базы данных из производства в наши тестовые среды, но что мне нужно изменить, чтобы тест работал, чтобы не мешать работе или случайно отправлять реальным клиентам электронные письма (помимо настройки web/%secure/base_urlс помощью URL-адреса теста)?

Еще один способ подумать об этом вопросе - подумать о том, как сгенерировать что-то вроде образцов данных Magento из моих собственных производственных данных.

1) DB Dump

Когда вы выполняете экспорт, вы можете экспортировать только структуру для следующих таблиц:

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

Также core_url_rewriteможно импортировать только со структурой и запускать URL-адрес каталога. Переписывает переиндексацию после импорта, если вам не нужны все эти записи (для различных тестов).

Вы также можете убирать оставленные корзины (подсказка:) sales_flat_quote, вы также можете удалять заказы, если они вам не нужны, и просто хранить ограниченное количество

2) Настройки конфигурации

• Web / (незащищенный | безопасный) / base_url
• контактные адреса электронной почты
• отключить электронную почту ( system/smtp/disable), чтобы вы не отправляли электронные письма по ошибке

3) Анонимизировать информацию о клиентах

• Вы можете использовать модуль Anonygento для Magento
• написать свой собственный сценарий, чтобы запутать информацию о клиентах / заказы на продажу / и т. д.

4) Настройки модуля

• Вы можете включить режим песочницы для модулей оплаты / доставки и сделать правильные настройки
• проверить модули, используемые для различной интеграции (либо отключить, либо установить их в режим песочницы)

Мы написали скрипт для обработки дампов БД для ветвления. Прочитайте эту статью .

Основным принципом является то, что он читает local.xmlдля извлечения учетных данных БД, а затем выводит данные на этой основе. Он разбивает дамп на две части, только структуру и затем данные. Но ключ в том, что он ускоряет обычный процесс дампа, пропуская несущественные данные , и наиболее критично предотвращает любые блокировки таблицы во время дампа, которые в противном случае заблокировали бы / повредили ваш работающий сайт.

Когда у вас есть дамп MySQL, вы можете очень легко изменить URL, просто используя sed

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

Затем запустите импорт MySQL в вашу новую БД.

Поэтому без сценария очень простая версия выглядела бы так.

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

Нет никаких причин для того, чтобы удалять файл local.xml или перезапускать программу установки, если вы изменяете URL-адреса в БД таким способом.

Весь процесс ветвления хорошо описан в нашем Руководстве по GIT Magento . Это хороший процесс для создания веток разработки, но он значительно сокращает количество работающих БД. Так что тесты не будут полностью такими же, как на живом сайте.

Таким образом, выполняя ванильный дамп БД, заменяя sed, импорта БД достаточно для промежуточного сайта. И будет отражать / соответствовать живому сайту как можно ближе.

С точки зрения предотвращения общения с клиентами - мы никогда не считали это необходимостью, поскольку мы всегда создаем учетные записи специально для тестирования, никогда не используя реальные заказы клиентов для тестирования.

Одним из вариантов решения проблемы с электронной почтой является настройка сайта разработки для перенаправления ВСЕХ писем к вам. Добавляет немного разума.

То, как вы это сделаете, зависит от вашей среды - для нас добавление этого в vhost делает работу:

php_admin_value sendmail_path "/usr/sbin/sendmail -i -- xyphoid@example.com,coworker@example.com"

Ничего. Изменение безопасных и незащищенных URL вполне достаточно.

Вы также можете опустить log_*данные таблиц, чтобы сделать ваш дамп легче.

Попробуйте это, он зашифрует электронные письма пользователей, чтобы помочь с вашей проблемой в случайных электронных письмах живых клиентов из тестовой среды

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