Какова лучшая стратегия развертывания?

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

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

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

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

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

Так:

• Какова ваша стратегия для развертывания?
• Есть ли модуль, способный сделать снимок системы Magento, позволяющий вам выбрать, что развернуть?
• если такого модуля не существует и если такой модуль является разумным решением, есть ли кто-нибудь заинтересованный в том, чтобы внести свой вклад в его разработку?

Спасибо!

Мое мнение состоит в том, чтобы написать все это. У меня обычно есть модуль базовой конфигурации для всего, что не связано напрямую с конкретными модулями функционально. (пример создания собственной перезаписи URL для предыдущего URL сайта в новый URL сайта) и добавьте все, что связано с модулем, в его собственные сценарии установки.

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

Изменения в тарифах на доставку, правилах корзин и т. Д. (В основном, вещи, которые клиенты администрируют сами в админке) считаются «изменчивыми данными» и не записываются в сценарии. Это включает в себя данные о продукте. У клиента есть возможность, и рекомендуется сначала протестировать новый импорт на сайте uat.

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

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

Я провел несколько исследований несколько месяцев назад. Вот сайты, на которые вы можете ссылаться.

URL-адреса Magento Base и установки dev / staging
Разработка и развертывание
Magento Руководство по Git Magento и рабочий
процесс Ускорение создания дамп базы данных Magento MySQL для ветвления

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

http://www.mageploy.com

Mageploy еще предстоит расширить, хорошо документировать и полностью протестировать, даже если я уже использую его в нескольких проектах, имеющих некоторые преимущества.

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

С уважением

Что касается установки сценариев и создания сущностей, мое общее мнение таково, что если это требуется или ожидается модулем, его следует создавать как часть сценария установки.

В последнее время, с точки зрения dev / stage / production, мы используем промежуточный сайт в качестве главной копии базы данных для контента, поскольку это означает, что клиент может сотрудничать. В прошлом, наверное, самая большая проблема, с которой мы сталкивались, - это координация ввода контента с клиентом, особенно в отношении загрузки продукта.

Как вы думаете, что снимок будет работать? Я думаю, что в идеальном мире у вас был бы инструмент, который показал бы разницу между двумя базами данных по определенным типам (продукты, категории, CMS и т. Д.) И позволил бы вам объединить изменения друг с другом, но я не знаю ничего доступного, например это.

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

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

Я хотел бы добавить два отличных инструмента для экономии времени:

• Для разработки: PhpStorm IDE с плагином Magicento
• Для развертывания: Magentify , рецепт Capistrano для Magento