Робочий процес Magento Development: як "керувати джерелами" бази даних та оновлювати живу установку Magento від установки тесту Magento?

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

Як і у всіх веб-розробках, звичайно, наявність живої копії та принаймні однієї копії розробки всього програмного рішення, звичайно, дуже важлива. Однак керування матеріалами Magento не схоже на керування іншим "файловим" програмним забезпеченням, тому що є також компонент бази даних, який вступає в гру, тому, крім того, що я можу використовувати такий інструмент, як Git, як інструмент VCS для управління джерелами, як би Мені ідеться про керування відмінностями в базі даних між прямою та живою версіями?

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

Це тіниста область життєвого циклу розвитку Magento, з якою я стикаюся: управління різницями в базі даних.

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

Отже, що є кращим способом керування синхронізацією бази даних між тестовим сервісом magento та сервером живого magento?

Спасибі.

Варіанти, які мені відомі

1.) Посібник - іншими словами, повторюючи ваші дії вручну в задній частині = як ви вже згадували, схильний до помилок, повільно

2.) На рівні бази даних з прямими запитами SQL = схильні до помилок

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

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

З усіх цих варіантів я зараз віддаю перевагу 3.)

Є mageploy, який також може вирішити цю проблему.

Існують такі інструменти бази даних, як жаба Quest Software (тепер Dell's) для MySQL. Цей інструмент управління базами даних має функції порівняння даних та структури, які можна використовувати для перегляду змін між двома базами даних. Просто зберігайте резервні копії (або git коміти) версій бази даних, які ви хочете порівняти, і voila. Існує навіть генератор сценаріїв для приведення двох в синхронізацію.

Ми вирішили цю проблему, створивши віддалений БД для локальних та постановочних розробок для читання / запису. Дійсно допомагає в часі та ефективності; не більше клонування, завантаження БД в оточення кожного.