Рекомендации по развертыванию Magento

Question

Я ищу настройку развертывания для высоко настраиваемого сайта Magento и задавался вопросом, как это делают другие люди.

Я буду настраивать среду разработки, UAT и prod. Все файлы Magento будут находиться в источнике управления (SVN). На этом этапе я не вижу никаких требований к изменению БД, поэтому 3 базы данных будут поддерживаться вручную.

В частности,

• Как применить обновления Magento? (Индивидуально в каждом env или на dev затем выкатывается или просто отказываетесь от апгрейдов?)
• Какие файлы/папки остаются в покое в каждой среде (например, magento/app/etc/local.xml)
• Do вы запрещаете разработчикам редактировать определенные файлы/папки?
• Вы ограничиваете дизайнеров темы редактированием определенных файлов/папок?
• Как вы управляете изменениями базы данных?

---

Theme Designer файлов/папок

Проектировщики могут ограничиваться редактирования следующих folders-

app/design/frontend/your_interface/your_theme/layout/ 
app/design/frontend/your_interface/your_theme/template/ 
app/design/frontend/your_interface/your_theme/locale/ 
skin/frontend/your_interface/your_theme/ 

---

Extension Разработчик файлов/папок

разработчики расширений могут редактировать следующие папки/Files-

/app/code/local 
/app/etc/modules/<Namespace>_<Module>.xml 

---

управления окружающей средой базы данных

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

• Переопределение базового url в php. Blog article on setting up dev and staging databases
• Изменение базового url в базе данных после копирования. (Где хранятся?)
• Выполнение MySQLDump или резервное копирование, а затем замена на URL в файле SQL.

Answer 1

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

Answer 2

Я использую git для управления всеми моими проектами и развертываниями Magento. Гораздо проще объединить новые версии, особенно если вы используете зеркало Magento, которое я поддерживаю на github.(GitHub Magento Mirror)

Как для вас конкретный вопрос о том, где базовый URL хранится в БД, попробуйте следующее:

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

Answer 3

Вы можете избежать DB-Manipulation (на немецком языке): http://blog.tudock.de/startseite/beitrag/2010/09/17/deployment-prozess-eines-magento-shops.html

Answer 4

Я рекомендую использовать git над SVN. Более легкое разветвление и слияние означает, что все эти точки будут более гладкими для вас.

Применение обновлений: Сделайте это в dev. Создайте ветку (именно там git действительно сияет), применяйте файлы исправлений или даже лучше, распакуйте новую версию Magento и укажите ее в свою старую базу данных. Пока нет расширений. Откройте администратора в новой установке Magento, надеясь на лучшее. Модификация между младшими версиями, вероятно, не будет проблемой. Вероятно, вам придется переиндексировать после установки нового материала. Сделайте фиксацию, как только это будет стабильно, затем постепенно добавьте в ветку ваши расширения и темы, внесите какие-либо корректировки кода, а затем совершите фиксацию после каждого шага, доказывая стабильность.

Файлы, зависящие от окружающей среды: .htaccess и приложение/etc/local.xml. Я делаю отдельную версию для каждого: local.dev.xml, Htaccess-DEV local.staging.xml, Htaccess-постановка local.production.xml, Htaccess производство

... а затем сделать softlinks в их для каждой среды:

ln -s htaccess-dev .htaccess 
cd app/etc/ 
ln -s local.dev.xml local.xml 

и так далее.

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

Управление изменениями базы данных: Это самая сложная часть. Мы просто используем mysqldump с производства и имеем готовые файлы «env-setup.sql» для каждой среды. Что-то вроде этого (ваши идентификаторы могут различаться):

UPDATE core_config_data SET value='http://magento.dev/' WHERE config_id IN (3,4); 

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

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

Вы можете получить данные CMS (страницы и статические блоки) из базы данных путем сброса и загрузки только таблиц cms_ * из любой среды разработки.

Удачи вам!

Answer 5

После многих проб и ошибок, мы придумали с рабочим процессом, который подходит нам хорошо:

http://www.dhmedia.com.au/blog/perfect-magento-workflow-using-git

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

Надеюсь, это поможет кому-то!