Яка найкраща стратегія розгортання?

Налаштування магазину Magento - це не лише питання розробки розширень, які можна встановити самостійно, але вимагає також багатьох операцій "ручного введення", таких як створення атрибутів кінцевого редагування, категорій, продуктів, правил цін на CMS-сторінках тощо, не кажучи вже про всіх зміни в конфігурації системи.

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

Одна з моїх стратегій - це написання "модуля розгортання", який програмно створює вищезгадані сутності, але це дуже трудомістка задача, і іноді мені здається, що це трохи зайве.

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

Можливо, оптимальним рішенням може стати використання модуля, здатного зробити знімок системи Magento, що дозволяє вам вибрати, що розгорнути.

Тому:

• яка ваша стратегія розгортання?
• чи є модуль, здатний зробити знімок системи Magento, що дозволяє вам вибрати, що розгорнути?
• якщо такий модуль не існує, і якщо такий модуль є розумним рішенням, чи є хтось зацікавлений у тому, щоб дати свій внесок у його розвиток?

Дякую!

Моя думка - це все це сценарій. Зазвичай у мене є базовий конфігураційний модуль для всього, що функціонально не пов'язане безпосередньо з певними модулями. .

Мислення за цим полягає в тому, що якщо сайт потрібно перевстановити, використовуючи свіжий db, то все повернеться так, як у вас це було. Це також допомагає в тому, що я періодично оновлюю uat-сайт з копією прямого db. Потім модулі uat продовжують працювати, коли вони знову прорізують свої конфігурації.

Зміни тарифів на оплату поштових відправлень, правила кошика тощо (в основному такі, що клієнти здійснюють в адміністраторі) вважаються "нестабільними даними" і не розписуються. Сюди входять дані про товар. Клієнт має можливість, і рекомендується спочатку перевірити новий імпорт на сайті uat.

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

Так, сценарій займає більше часу, але пізніше буде відтворено цілі налаштування конфігурації сайтів вручну пізніше. Це також може бути бентежно, якщо ви щось забули і змусили сайт не працювати належним чином, або ви працюєте з новим розробником на локальному веб-сайті, якому не вистачає певної важливої ​​настройки конфігурації.

Я займався деякими дослідженнями кілька місяців тому. Ось сайти, на які можна звернутися.

Базові URL-адреси Magento та установки
розробки / постановки Magento Розробка та розгортання
Magento Git Керівництво та робочий потік
Швидше скидання бази даних Magento MySQL для відділення

Я хотів би подякувати всім вам за те, що ваші міркування надихнули і підштовхнули мене розробити розширення під назвою "Mageploy" з наміром вирішити проблему підтримки синхронізації різних середовищ.

http://www.mageploy.com

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

Це відкритий код, і будь-яка допомога чи пропозиція буде оцінена.

З повагою

Що стосується встановлення скриптів та створення об'єктів, моє загальне відчуття полягає в тому, що якщо модуль цього вимагає або очікує, він повинен бути створений як частина сценарію встановлення.

Останнім часом, з точки зору розробника / сцени / виробництва, ми використовуємо сайт постановки як основну копію бази даних для вмісту, оскільки це означає, що клієнт може співпрацювати. У минулому, мабуть, найбільша проблема, з якою ми стикалися, - це узгодження вмісту з клієнтом, особливо щодо завантаження продукту.

Як ви думали, що знімок спрацює? Я думаю, що в ідеальному світі у вас є інструмент, який би показав різницю між двома базами даних для конкретних типів (продукти, категорії, CMS тощо) і дозволив би вам об'єднати зміни один з одним, але я не знаю нічого доступного, наприклад що.

На мою думку, створення та редагування атрибутів, категорій, продуктів, правил цін не має нічого спільного з "стратегією розгортання". Усі ці товари досить унікальні для магазину, і в більшості випадків вимагають належного аналізу та дослідження продуктів, які ви збираються продати.

Якщо ви створюєте магазини "один розмір, що підходить для всіх" з подібною конфігурацією всіх згаданих вами елементів, ви зможете просто здійснити "екстрений" експорт вашої бази даних після того, як ви виконали всі необхідні налаштування для кожного магазину.

Я хотів би додати два чудових інструменти економії часу:

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