Як з'єднати зміни з розробленої копії сайту на веб-сайт, що живе в реальному часі, не втрачаючи нового вмісту?

Який найкращий порядок об’єднання робіт, виконаних над розробкою копії сайту, до копії в режимі реального часу? Часто на сайті було додано багато нового контенту, оскільки почалася розробка новітніх функцій. І більшість доповнень до сайту стосуватимуться змін у базі даних. Тож копіювати будь-які нові файли досить просто, але як бути з базою даних? Як ви об'єднаєте свої зміни з існуючою базою даних виробництва, не втрачаючи нового вмісту, який було додано з моменту останнього оновлення виробничого сайту? Чи є модулі, які допомагають у цьому?

Для типів вмісту, переглядів та змін структури на веб-сайті розробника дивіться за допомогою функцій для експорту бази даних у код.

Для міграції вмісту існує багато варіантів, але не існує єдиного твердого рішення. Одним із прикладів є набір розгортання .

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

1) Розгортання, скидаючи виробничу базу даних та імпортуючи mysqldump бази розробки. За бажанням заздалегідь запустіть знаходження / заміну регулярного вираження на будь-яких жорстко закодованих абсолютних посиланнях, які посилаються на URL-адресу розробника на дамп SQL. Після імпорту dev db в prod автоматично запустіть оператори SQL (як правило, через скрипт), щоб потім змінити будь-які параметри, які відрізняються для prod, ніж dev (наприклад, можливо, у таблиці змінних є деякі параметри підключення для підключення до зовнішніх систем, які вам потрібно зміна на точку на зовнішніх системах prod, а не на версію розробника).

2) Використовуйте модуль " Особливості" , як згадував budda, для налаштувань адміністратора та використовуйте модуль " Експорт вузлів" для експорту / імпорту вмісту в поєднанні з модулем " Видалити все" . Отже, робочий процес такий:

1. використовувати node_export та функції для експорту вузлів / функцій у файли
2. Необов'язково (і сподіваємось) контроль версій
3. Завантажте файли в систему prod
4. Використовуйте інтерфейс drush або admin для завантаження функцій
5. Використовуйте drush delete all або інтерфейс адміністратора, щоб видалити всі вузли типів, які потрібно імпортувати
6. Використовуйте drush ne-import або адміністраторський інтерфейс для імпортування вузлів із експортованого файлу вузлів.

Одне зауваження, я б настійно пропонував прийняти стандартний робочий процес, де вміст йде лише в одному напрямку. Або Dev -> Prod або Prod -> Dev (я віддаю перевагу цьому).

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

Дамп баз даних копії та копії розробки сайту у файлі SQL (використовуйте однакові параметри та параметри для обох дампів).
Потім порівняйте обидва файли SQL, використовуючи невеликий інструмент порівняння ExamDiff . Він відображатиме різниці файлів поруч із різними кольорами. Ви також можете безпосередньо перейти до відмінностей (без прокрутки). Вивчіть відмінності та додайте / редагуйте рядки до файлу SQL живого сайту. Переконайтеся, що в цьому файлі немає абсолютного шляху / URL середовища розробки. Це зроблено! Час відновити базу даних для живого сайту.
Зробіть своє життя простішим:На першому кроці завантажте лише ті таблиці, які змінені. Наприклад, якщо ви відредагували модуль у копії розробки, націлений на окрему таблицю, скиньте лише цю таблицю. Якщо ви не впевнені в конкретній таблиці, цілий дамп бази даних добре.