Постановка сайтів, як ви керуєте синхронізацією оновлень у БД?

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

Єдиний (заплутаний) потік, який я можу собі уявити, такий:

1. Тест на локальному сервері (WAMP, XAMP тощо)
2. Після готовності до розгортання переведіть веб-сайт в режим обслуговування
3. Резервне копіювання живого веб-сайту (копіювач, sqldump тощо)
4. Створіть клон заблокованого живого сайту до інсценізаційного сайту
5. Завантажте модифікації з місцевого середовища на інсценізаційний сайт
6. Перевірте місце постановки
7. Натисніть на інсценівку, щоб жити.
8. Вийміть режим обслуговування

Недоліки потоку вище:

• час простоїв для користувачів може бути довшим, ніж очікувалося, поки розробник ретельно перевіряє оновлення на веб-сайті;
• може знадобитися вручну керувати модифікаціями: наприклад, макети веб-сторінок siteorigin зберігаються у db, тож як тільки макет буде змінено, його потрібно імпортувати вручну на місце постановки; у цьому випадку може бути адекватним просто випустити та імпортувати сторінки на веб-сайт, а якщо працює, імпортувати їх у реальному веб-сайті

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

Як ти гадаєш?

EDIT, за запитом, деякі рішення були запропоновані в минулому, але жодне не пропонує остаточного рішення:

• 9/2010 - Синхронізація бази даних між розробкою / постановкою та виробництвом
• 12/2011 - Розгортання оновлених чи нових плагінів, що змінюють таблицю wp_options
• 9/2014 - Як завантажувати локальні зміни на живий сервер без зміни нових повідомлень / сторінок?
• 1/2015 - Як підтримувати блоги сайту wordpress у виробництві та постановці?

Нові хостинг-провайдери, які спеціально обслуговують WordPress, зазвичай мають інструменти для полегшення цього болю. Я розміщую своїх клієнтів на Pantheon, який має цей акуратний робочий процес із підтримкою Git , де код рухається лише вгору (від розробки до постановки на виробництво), а БД - лише вниз (навпаки від коду). Копіювання бази даних від виробництва до постановки - це один клік з їх інтерфейсом. За умови дотримання цього робочого процесу це в значній мірі усуває проблему з тим, що коли-небудь псують виробничу базу даних, що дозволяє мені завжди перевіряти свої зміни на новому клоні даних виробничих БД у будь-якому етапі розвитку.

Не потрібно використовувати Pantheon - ви можете застосувати подібний підхід у своєму процесі, використовуючи власні інструменти (Git + плагін для клонування БД, як WP Migrate DB). Я просто вважаю, що цей спосіб працює для мене добре.

Запитання: навіщо ви переводили свій виробничий майданчик у режим технічного обслуговування під час тестування етапів? У більшості випадків цього не повинно бути. Єдиний випадок, про який я можу подумати, - це наявність якоїсь дуже крихкої системи, чутливої ​​до додаткових даних користувачів, що надходять до неї, з катастрофічною помилкою для завантаження - але це, ймовірно, свідчить про іншу, більшу, проблему, де потрібно переосмислити всю архітектуру продукту.

Погляньте на VersionPress, який приносить версію GIT до всього процесу (файлів та бази даних)

Як описано на їхньому сайті:

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