Проведение и производство Magento

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

Может ли кто-нибудь предложить хорошие процессы для этого - до сих пор я просто экспортировал/импортировал базу данных разработки, копировал исходные файлы, очищал тестовые заказы, клиентов и т.д., затем менял базовые URL-адреса, файлы htaccess и т.д.

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

Ответ 1

Мой процесс обычно управляется в репозитории управления версиями (SVN в моем случае), что делает вещи намного проще (или возможно, действительно...). Идея состоит в том, чтобы сохранить все возможное в репо и использовать обновления SVN и теги для публикации изменений.

local.xml. Я перемещаю этот файл в SVN на local.xml.dist и игнорирую фактический файл local.xml в репо. Это позволяет использовать разные учетные данные и хосты на вашем компьютере без загрязнения кода.

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

настройка хоста. Моя среда промежуточного уровня и среды разработки настроены на запуск/выключение из репозитория. Разработка происходит здесь и может быть перенесена на стадию (или по требованию) через svn up, чтобы показать новые функции клиенту и сделать UAT. Производственная среда требует некоторой защиты от Дикого Запада от ствола, тем не менее, так что среда течет. Всякий раз, когда набор функций готов выйти, я создаю новый тег из внешней линии и делаю svn switch для перехода к новому набору кода. Ведение дел таким образом также дает мне легкое отключение для производства (вернитесь к последнему тегу). Таким образом, я удалил все ручные файлы из моей жизни, что хорошо.

Еще лучшая система (которой мне еще не нужна) - использовать svn export для создания полной копии дерева кода в производственной системе и использовать ln для переключения между ними. Что-то вроде этого:

> cd /home/apacheuser
> ls -l
www -> /home/apacheuser/tag_1.0.1
tag_1.0.1

> svn export /url/for/repo/tags/1.0.2 tag_1.0.2
... svn exports here ...

> rm www; ln -s /home/apacheuser/tag_1.0.2 www

Таким образом, изменения версии мгновенно.

db sync back from production. Чтобы позволить мне работать с производственными данными, у меня есть задание cron, предназначенное для сброса производственной базы данных и импорта ее в стадию. Пока это происходит, script удалит конфиденциальные данные клиента (и изменит адрес электронной почты клиента, чтобы все электронные письма пошли ко мне). Он также изменит настройки шлюза кредитной карты на тестовый шлюз и изменит параметры base_url, чтобы URL-адреса промежуточного сайта работали правильно.

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

Единственный способ справиться с этой сложностью (и правильным образом, в то же время!) - убедиться, что сам код отслеживает необходимые изменения в среде. Magento поддерживает автоматическую модернизацию версии модуля, включая сценарии базы данных, которые вы должны использовать для внесения изменений схемы и т.д. Это означает, что при развертывании нового кода для промежуточного/производственного процесса (или, как вы получаете его от другого разработчика в среде вашего разработчика) все патчи базы данных применяются автоматически.

Это также означает, что вам нужно написать новые функции как можно более неразрушающими. Темы Magento, отключенные модули и т.д. Могут использоваться, чтобы сделать это реальностью. Например, при создании новой темы для сайта не следует изменять какое-либо основное поведение и сохранять все новые активы в теме, которая будет инертной по производству до развертывания.

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

Сообщите мне, если это было непонятно. Надеюсь, что это поможет!

Спасибо, Джо

Ответ 2

1) Скопируйте файлы. Очистите папки var/cache и var/session.

2) Экспортируйте базу данных, создайте промежуточную базу данных и импортируйте этот файл дампа.

3) Обновите файл приложения /etc/local.xml с помощью новой информации о промежуточной базе данных.

4) Измените свою базу данных с помощью инструмента, такого как PHPMyAdmin, и отредактируйте таблицу "core_config_data", чтобы обновить базовые URL-адреса (/web/secure и /web/unsecure )

для этого Запустите запрос:

 SELECT * FROM core_config_data WHERE path = 'web/unsecure/base_url' OR path = 'web/secure/base_url';

и измените значения приведенных строк.

5) Если у вас есть доступ к SSH, запустите эту команду в корневом каталоге хранилища промежуточных хранилищ:

./pear mage-setup .

6) Запустите веб-сайт в браузере