Преобразование производственной базы данных в тестовые данные
Чем ближе тест к производству, тем лучше он может имитировать производственное поведение. Я хотел бы скопировать резервные копии базы данных из рабочей среды в наши тестовые среды, но что мне нужно изменить, чтобы тест работал, и чтобы не мешать работе или случайно отправлять по электронной почте реальным клиентам (кроме установки web/%secure/base_url с URL-адресом теста)?
Другой способ обдумать этот вопрос - рассмотреть, как создать что-то вроде Magento Примеры данных из моих собственных производственных данных.
5 answers
1) Дамп БД
Когда вы выполняете экспорт, вы можете экспортировать только структуру для следующих таблиц:
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) Конфигурация Настройки
- веб/(небезопасный|безопасный)/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-адреса в БД таким образом.
Весь процесс ветвления хорошо описан в нашем Руководстве Magento GIT. Это хороший процесс для создания ветвей разработки, но он значительно сокращает живую базу данных. Таким образом, тесты не будут полностью такими же, как на живом сайте.
Таким образом, для промежуточного сайта достаточно выполнить дамп базы данных vanilla, заменить sed, импортировать базу данных. И будет отражать/соответствовать живому сайту как можно точнее.
С точки зрения предотвращения общения с клиентами - мы никогда не считали это необходимым, так как мы всегда создаем учетные записи специально для тестирования, никогда не используя реальные заказы клиентов на тестирование.
Одним из вариантов решения проблемы с электронной почтой является настройка сайта разработки для перенаправления ВСЕХ электронных писем вам. Добавляет немного ума.
Как вы это сделаете, зависит от вашей среды - для нас добавление этого в vhost делает работу:
php_admin_value sendmail_path "/usr/sbin/sendmail -i -- [email protected],[email protected]"
Ничего. Изменения безопасных и небезопасных URL-адресов вполне достаточно.
Вы также можете опустить данные таблиц log_*, чтобы облегчить ваш дамп.
Попробуйте это, это скремблирует электронные письма пользователей, чтобы помочь решить вашу проблему при случайной отправке по электронной почте реальных клиентов из тестовой среды
UPDATE customer_entity SET email = REPLACE(email, '@', '-test@abcxyz123-')