как безопасно развернуть базу данных stage в живую производственную базу данных в magento - PullRequest
4 голосов
/ 25 января 2012

Будучи очень новичком в управлении версиями и управлении исходными кодами, мне интересно, как некоторые из вас прошли безопасное обновление изменений в своей базе данных dev до производства с использованием Magento и какие инструменты помогут вам сделать это.

У меня есть настройка репозитория для моих изменений dev и локальный компьютер, на котором работает dev версия magento, но я не знаю безопасного (и правильного) способа объединения моих изменений базы данных. Что, если я добавлю несколько продуктов, добавлю расширение, изменим некоторые настройки администратора в своей среде разработки, но захочу объединить мои изменения с живым магазином, который принимает заказы, добавляет покупателей и т. Д.? Я бы подумал, что какой-то тип слияния будет уместным, почти как управление исходным кодом для базы данных, но возможно ли это вообще?

Я не уверен, помогает ли это или имеет значение, но я использую NetBeans и часто использую Navicat для просмотра таблиц БД и тому подобного.

Ответы [ 2 ]

4 голосов
/ 26 января 2012

Схема управления версиями базы данных
Не очень актуально - поскольку каждый модуль в Magento может иметь свой собственный набор сценариев установки / обновления . Тем не менее, если интересно, есть инструменты для управления схемой базы данных, такие как dbDeploy .

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

Как работает тянущий бизнес
Вытащить (и протолкнуть) базу данных довольно просто, для базы данных выполняется mysqldump, затем выполняется поиск / замена (с использованием sed или чего-то подобного) с изменениями URL-адресов, а затем импортируется в новую базу данных.

Сказав, что ...
Слава вам за то, что ваш исходный код версионирован, это по крайней мере означает, что если вы do должны следовать моему сценарию, вы можете полностью протестировать модуль в среде разработки, прежде чем вносить изменения в продукт. Хотелось бы предложить больше конкретного «решения» - поскольку внесение изменений в нескольких средах, безусловно, не идеально, хотя мне будет интересно, что предлагают другие.

0 голосов
/ 14 ноября 2013

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

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

Или я могу предложить использовать инструмент автоматической миграции, который будет сравнивать промежуточную и производственную базы данных и передавать все продукты или атрибуты, которые пропустили на сервер. http://xpscommerce.com/blog/quick-push-magento-database-to-production/

Передача продуктов также включает в себя передачу изображений.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...