Как поддерживать синхронизацию тестирования и производства электронной коммерции при наличии обновлений «продаж» на производстве? - PullRequest
1 голос
/ 05 февраля 2010

Я читал следующую ветку в SO, Поддержание чистоты, синхронизации и согласованности сред тестирования и рабочих серверов , и у меня все еще есть некоторые сомнения в том, как лучше всего это сделать.

«Вы должны внести изменения в свою тестовую среду и скопировать ее на свой рабочий сервер». Проблема в том, что я использую Magento установку: у меня есть разные модификации в тестовой и производственной среде в разное время (например, продажи на производственном сервере), и я не знаю, как лучше их сохранить синхронизации.

«Копать» в структуре таблицы Magento будет очень сложно, так как существует более 200 таблиц.

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

Заранее спасибо!

Ответы [ 4 ]

2 голосов
/ 08 сентября 2011

Я знаю, что опаздываю, но я только что опубликовал скрипт, который синхронизирует производственные базы данных с подготовкой.

http://markshust.com/2011/09/08/syncing-magento-instance-production-development

Как правило, ничто не должно быть важным при постановке, поскольку оно может быть перезаписано в любой момент - это должен быть точный клон производства для тестирования в среде, которая почти точно имитирует производство.

В разработке (или на вашем локальном компьютере) вы тестируете обновления или изменения кода перед его отправкой в ​​стадию для тестирования развертывания.

1 голос
/ 06 февраля 2010

Я управляю сайтом Magento с рабочим экземпляром, несколькими экземплярами разработки и экземпляром тестирования.

Magento, как правило, довольно чист в хранении метамодели и информации о конфигурации базы данных в коде. Каждый модуль поставляется со сценариями базы данных, которые он должен запустить для установки самого себя, и Magento довольно хорошо запускает их автоматически, когда появляется код для модуля. Есть некоторые параметры конфигурации, которые изменены в администраторе и хранятся в базе данных, но очень немногие. Это отличается от некоторых систем, например Drupal, где в базе данных хранится огромное количество метамодельной информации, которая никогда не отражается в коде.

Что я делаю, так это отслеживаю кодовую базу в управлении версиями. Например, я установлю новый модуль в версии для разработчиков. Как только код заработает, я помечу его в системе управления версиями, вытолкну тег в экземпляр теста и скопирую базу данных из рабочей среды в экземпляр теста. Это дает мне точную картину того, как будет выглядеть производственная система. (При перемещении базы данных Magento от экземпляра к экземпляру требуются небольшие изменения. Подробности см. в этом ответе .)

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

Если вам необходимо настроить параметры автоматической и мгновенной конфигурации при развертывании, вы можете указать параметры конфигурации по умолчанию, которые вам нужны в файле config.xml, который будет загружен после вашего модуля (то есть зависит от вашего модуля). Я никогда не делал это таким образом, но я не вижу причин, почему это не сработало бы.

Любые изменения в действующих данных (изменение цен по всем направлениям и т. Д.), Я пишу сценарий для dev, тестирую копию действующей базы данных и внедряю в производство.

Надеюсь, это поможет.

1 голос
/ 06 февраля 2010

Быстрый ответ: Magento enterprise должна позаботиться об этом, позволяя вам запускать промежуточные сайты, а затем синхронизировать контент, такой как цены и продукты, через интерфейс администратора. У меня нет полного успеха с этим, но идея есть.

Когда дело доходит до кода, вы все равно сможете использовать среды без особых затруднений. Например, изменение внешнего вида вашего сайта или добавление новых плагинов может не требовать изменения базы данных и поэтому должно быть безопасным.

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

Таким образом, изменения в каталоге становятся вероятной проблемой. Я бы посоветовал просто внести эти изменения в действующий сайт (поскольку они являются стандартными данными) и проверить конфигурацию элементов перед тем, как сделать их видимыми. Вы также можете стереть определенные таблицы для продуктов (но не продаж) и перезагрузить их из тестовой базы данных, но это приведет к отключению вашего сайта на некоторое время при синхронизации.

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

Спасибо

Джо

0 голосов
/ 06 февраля 2010

Используйте GIT, создавайте удаленные ветви, производственную ветку, ветку выпуска, обновляйте ее, объединяйте, когда это необходимо. Вы можете найти больше: http://git -scm.com / и http://github.com/

...