Тримаючи синхронізовану базу даних WP для кількох розробників за допомогою git

Я працюю над вдосконаленням свого робочого процесу git, як це стосується моїх проектів розвитку WordPress. Часто, розробляючи систему управління вмістом, я створю сервер розробки (як http://dev.finalsitename.com), що містить власні типи публікацій та таксономії, які будуть використовуватися у виробничій версії. Це дозволяє моєму клієнту почати додавати свій вміст на сайт.

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

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

Що ще роблять розробники, щоб синхронізувати свої бази даних, одночасно дозволяючи декільком розробникам (та клієнтам / виробникам контенту) працювати над одним проектом?

Є три варіанти від найпростішого ->

1. Використовуйте лише одну віддалену базу даних, до якої всі ви підключаєтесь із великою кількістю резервних копій. Таким чином, ви просто повинні турбуватися про файли, а не про db.

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

3. Використовуйте спеціальний скрипт оновлення для версії фактичної синхронізації бази даних. Я, чесно кажучи, не знаю, як ти можеш цим керувати за допомогою git, тому що це просто сценарій і насправді не знає, що відбувається, я знаю, що є сторонні інструменти, які роблять це комерційно та безкоштовно ( http: // www. liquidibase.org/ ).

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

Або якщо ви хочете зберегти дані від виробництва, але розвинути його схему, ви можете працювати з користувацьким рішенням (версійний файл із усіма змінами схеми) або зі стандартним рішенням, заснованим на концепції migration. Ви можете знайти багато інформації в цій потоці stackoverflow: Механізми відстеження змін схеми db .

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

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

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

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