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


82

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

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

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

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

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

Так:

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

Спасибо!


Это может указывать на необходимость использования другого тега или категории тегов. Вы специализированный магазин или ищете общие предложения в качестве поставщика услуг? Если последнее, любой ответ должен был быть приправлен "зависит от того, какой контроль клиент хочет над данными объекта".
отметки

Моя точка зрения - это точка зрения разработчика из команды разработчиков. Предположим, я разрабатываю раздел, который нуждается в некоторых данных для работы, скажем, в структуре категорий. Я создаю структуру через Admin, делаю код и добавляю мой код. Я задаюсь вопросом, является ли лучшая стратегия в том, чтобы также писать и выдвигать код, который создает необходимую структуру категорий. Что если структура или настройки моей категории противоречат другим разработчикам, которые выдвинули свои собственные? Как мне справиться с конфликтами? Это моя точка зрения.
Алессандро Рончи

@AlessandroRonchi Это спорный вопрос и конфликт, который никогда не должен случиться. Ваша структура категории не должна быть чем-то легкомысленным, поэтому один разработчик не должен продвигать серьезные изменения в вашей структуре, если другие не знают об этом. Если это произойдет, вам нужно обратиться к вашему inter-dev общению. Как правило, структуру категорий для сайта необходимо определить с самого первого дня, и никогда не нужно менять ее, просто добавьте. Если вам нужно изменить его, вы не правильно корректировали его с первого раза.
ProxiBlue

@dedmeet, к сожалению, в мире, в котором я знаю и работаю, все меняется каждый день; клиенты меняют свое мнение, разработчики меняют свое мнение, появляются черные лебеди. Я должен быть готов к изменениям; в любом случае, даже если структуру категории не нужно менять с первого дня, это всего лишь небольшой фрагмент всей части, и вся эта часть - это «незавершенный» проект, который должен измениться, чтобы добиться цели.
Алессандро Рончи

Хорошо, конечно, мы работаем в постоянно меняющейся среде, но я все еще верю, что конфликт структуры категории не должен произойти. Несколько ветвей не должны существовать там, где каждая изменяет структуру, что просто приведет к проблемам и пустой трате времени разработки. Почему dev тратит время на изменение структуры, в то время как dev b делает то же самое для другой структуры, и они оба продвигают свою работу? Если структура должна измениться, все разработчики, вовлеченные в проект, должны быть вовлечены в процесс определения новой структуры. Можете ли вы привести пример, чтобы помочь мне понять, когда это может произойти?
ProxiBlue

Ответы:


39

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

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

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

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

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


1
Я согласен с dedmeet. Когда вы впервые узнаете, как создавать сценарии для всех обновлений, это может быть более начальной работой, но если вам придется применять обновления конфигурации вручную для 3-4 разработчиков, постановка, подготовка и запуск, координация и фактическая работа займет намного больше времени. Наш рабочий процесс очень похож: если конфигурация необходима для (многоразового) расширения, поместите его туда. Если конфигурация зависит от клиента, поместите его в расширение для конкретного проекта. Одним из немногих исключений являются правила корзины, которые совсем не интересно обновлять / создавать.
Матиас Зейс

1
Я просто выпускаю модуль, который помогает создать требуемый скрипт конфигурации, устраняя тем самым рутинную работу по созданию сценариев установки вручную. Модуль использует отображение сетки таблицы core_config_data, чтобы разрешить выбор значений конфигурации для экспорта. Сделайте мою жизнь немного проще, и я надеюсь, что это сработает для других. proxiblue.com.au/blog/magento-config-data-generator
ProxiBlue

27

1
Спасибо, я прочитаю их все и вернусь с некоторыми соображениями.
Алессандро Рончи

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

Дорогой Алессандро, я хотел бы видеть твой путь, который я тоже ищу более удобной техникой!
Огуз Челикдемир

18

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

http://www.mageploy.com

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

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

С уважением


7

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

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

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


1
«Что касается установки сценариев и создания сущностей, у меня общее ощущение, что, если это требуется или ожидается модулем, его следует создавать как часть сценария установки». Это наиболее важный момент для рассмотрения и применяется к настройкам конфигурации. Мой быстрый тест: когда мне нужен новый разработчик для клонирования репозитория и установки среды, что должно существовать для функционирования системы?
отметки

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

6

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

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


Нет, «один размер подходит всем» - не главное; Это та же самая ситуация, с которой мы, как разработчики, сталкиваемся, когда пришло время объединить наш исходный код с кодом другого члена команды разработчиков: в этом случае у нас есть системы контроля версий, которые совершают чудеса. Мой вопрос был больше связан с возможностью слияния "не dev" вещей, таких как настройки конфигурации и типичные настройки администратора и записи.
Алессандро Рончи

Ах, хорошо, это делает это более ясным
Рутгер

Допустим, мы создаем совершенно новый веб-сайт, поэтому никаких проблем со старыми данными и т. Д. Почти все наши разработчики используют для разработки одной и той же базы данных. Это решает много проблем. В других случаях у меня нет лучшего решения (пока), чем выписать все шаги, необходимые для какого-либо плана / сценария, и повторно применить их все после слияния. Если за настройки администратора «magento core» отвечает только один человек, это не должно включать много шагов. Однажды я нашел это, но никогда не пробовал: tinybrick.com/magento-modules/admin-tools/…
Рутгер,

2

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

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

Спасибо, что сообщили нам о Magentify, я не знал, и я попробую. Хотя я сосредоточился на синхронизации другой среды разработки, а не на развертывании в смысле публикации базы кода. Mageploy может быть интегрирован с Magentify, но это другой инструмент, который используется для автоматического выравнивания некоторой части изменений базы данных независимо от конкретных идентификаторов, которые различаются в разных средах. С уважением, Алессандро
Алессандро Рончи
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.