Фон

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

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

Моє запитання:

Чи є простий спосіб автоматизувати об'єднання баз даних, щоб кілька людей могли працювати над встановленням WordPress? Я, звичайно, міг би просто експортувати таблиці, які, як я знаю , змінилися на моїй локальній машині, і перенести їх на інсталяційний сервер, але можливо, на сервері інсценізації також є речі, які я хотів би збити. Я міг би схопити вихід SQL обох БД і розмежувати їх ... але це здається нудним і хакерським. Мені цікаво, чи це проблема, яку вирішили інші; якщо існує такий спосіб вирішення подібних речей.

Спасибі!

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

Все в Git

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

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

Нас також врятував Git. Звичайно, це дозволяє нам повертати зміни, що чудово, але це також дозволяє повернути старі версії файлів. Це означає, що якщо клієнт запитує: "Згадайте, як ця частина сайту працювала близько року тому? Чи можемо ми повернути це?", Відповідь - так, навіть якщо запитувана особа не була в цьому проекті рік тому.

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

Використовуйте Git для розгортання

Ми проводимо WordPress хостинг на Media Temple , і нам вони дуже подобаються. Вони не найдешевший постачальник, але їх сервіс чудовий і їх сервери справді налаштовані. Також надайте Git за замовчуванням. Це означає, що ми можемо налаштувати сервер як сховище Git і таким чином витягнути зміни замість SFTP. Це також означає, що виконання роботи над сервером не загрожує перезаписом (оскільки ці зміни можна просто об'єднати і відсунути назад).

Оскільки ми використовуємо BitBucket як наш Git-хост, тут потрібно трохи додаткової роботи. Перш за все, ми використовуємо .ssh / config файли, щоб ми могли вводити такі речі, як ssh sitenameувійти на наші сервери (ми також використовуємо SSH без паролів , що робить це дуже просто). Ми також переконуємось, що завжди використовуйте SSH-фрази (Mac OS X робить це дуже просто, дозволяючи зберігати свою парольну фразу в Keychain.app ). Нарешті, ми додаємо рядок ForwardAgent до запису .ssh / config на хостах, з яких ми хочемо вийти. Це означає, що нам потрібен лише відкритий ключ SSH для кожної людини в BitBucket, а не відкритий ключ кожного сервера. Ми також не забудьте зберегти .gitкаталог один каталог над загальнодоступним каталогом HTML.

Автоматизовані звалища баз даних

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

У кожного є свій wp-config

Оскільки у нас є власні імена користувачів і паролі локальної бази даних, і тому що ми могли використовувати різні імена та механізми обслуговування, кожен з них зберігає свій власний файл wp-config. Кожен із них зберігається в Git з таким ім'ям wp-config-gavin.php, і коли ми хочемо використовувати цю конфігурацію, ми посилаємо його на wp-config.php(що ігнорується Git за допомогою .gitignore ).

Це також дозволяє нам перекрити siteurl параметр у wp_optionsтаблиці бази даних так:

define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');

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

Останнє зауваження про файли wp-config.php: переконайтеся, що зберігаються над загальнодоступним каталогом HTML і дозволяють прочитати дозволи лише для веб-користувачів . Це робить величезну різницю в забезпеченні WordPress.

Випуск бази даних

Нарешті, м'ясо матерії.

Що мені довелося погодитись, це те, що при використанні WordPress немає хорошого способу "злити" зміни бази даних. Натомість нам потрібно було розробити правила поведінки, щоб вирішити це. Правила досить прості, і нам добре служили до цих пір.

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

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

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

Я працюю над такою установкою і раніше відповідав на такі питання . Нижче наведено моє переважне налаштування для такого роду робіт. Оскільки ви хочете об'єднати бази даних замість заміни існуючої бази даних, я б додав до них обережність не використовувати прапор --add-drop-table під час виконання дампа MySQL.

• Крок 1. Mysqldump вашу базу даних розробок
• Крок 2. Замініть всі екземпляри development.domain.com на production.domain.com ^^
• Крок 3. Увійдіть до MySQL, запустіть команду SOURCE для імпорту даних, наприклад source /path/to/file

^^ Як замінити всі екземпляри старого домену на нові: (1) Скопіюйте сценарій нижче. (2)chmod +x це. (3) Виконати його.

Використання: ./script.sh development-dump.sql > production-dump.sql

#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g

Я зараз експериментую з різними рішеннями цієї ж проблеми. Це, безумовно, хитро.

Моє поточне рішення - зробити локальний дамп mysql, використовуючи прапор --skip-extension-insert. Я вважаю, що цей прапор спричиняє згенерування запису вставки для кожного ряду бази даних, що робить дамп трохи більш зручним для злиття. Я взяв цей трюк із цієї статті: http://www.viget.com/extend/backup-your-database-in-git/ .

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

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

Я можу врешті встановити нам спільну базу даних розробників на сервері та спробувати підключити обидві локальні копії веб-сайту до тієї ж БД через тунелювання SSH. Такий підхід, однак, виникне у проблемах кожного разу, коли хтось із нас встановить плагін. Фактично файли PHP та MySQL DB не синхронізуються.

Мені хочеться почути, як інші вирішують цю проблему.