Чи є у вас ефективні стратегії запуску v2 веб-сайту WP?

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

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

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

Ми тільки почали говорити про наш процес випуску продукції. Значення: як тільки ми закінчимо, як ми будемо плавно і з якомога меншими перебоями отримувати весь наш користувальницький код на виробничому (живому) сервері?

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

Якщо ви будете дотримуватися порад SethMerrick, ви можете значно скоротити час перемикання, знизивши TTL на відповідних записах DNS до 5 хвилин або близько цього на кілька годин (залежно від того, що є поточним TTL) перед тим, як змінити IP-адресу.

Роблячи це, ви говорите віддаленим серверам DNS лише кешувати адресу протягом 5 хвилин. Після зміни IP-адреси ви можете збільшити TTL до того, що було раніше. Щоб додатково мінімізувати ефект, робіть перемикання протягом низького періоду руху.

Я не впевнений, чи це застосовно, але я просто пройшов подібний процес одночасної міграції та модернізації сайту з високим трафіком.

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

Складний біт полягає в тому, щоб потім об'єднати всі дані, що накопичуються під час розповсюдження DNS, на стадіонний сервер (який зараз є живим сервером). Іншими словами, якщо пройде 30 годин між тим, як ви робите дамп / оновлення DNS mysql, і коли розповсюдження DNS завершено, вам доведеться вибірково об'єднати 30 годин записів зі старого сайту на новий.

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

@ Майк Лі: Велике запитання і один із святих граалів WordPress (або будь-якого з основних CMS з відкритим кодом, з яким я знайомий з цього питання, таких як Drupal, Joomla та ін.)

Хоча це, звичайно, не призначено для вирішення ваших випадків використання, перегляньте мою відповідь на відповідне запитання, яке описує плагін рівня бета-версії, який я щойно зробив доступним через обмін відповідями WordPress під назвою WP Migrate Webhosts (так, я смоктав, коли справа стосується творчих імен .)

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

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