Синхронизация базы данных WP между несколькими разработчиками с помощью git

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

Пока они работают над этой задачей, я обычно создаю внешний вид, а также настраиваемые программы / плагины, которые будут использоваться в моей среде localhost. Чтобы гарантировать, что я не перезаписываю их обновления, я обычно вытаскиваю копию их базы данных и заменяю свою. Однако бывают случаи, когда мне просто нужно прыгнуть в админку WP и изменить настройку или что-то еще маленькое ...

Если над проектом WordPress работают несколько разработчиков, каждый из нас делает (помеченный меткой времени) дамп базы данных нашей версии сайта и включает его в корневой каталог перед фиксацией и отправкой их локальной ветви обратно в удаленный репозиторий. Проблема с этим подходом состоит в том, что базы данных часто не синхронизированы, и нет простого способа определить, какой из них использовать.

Что делают другие разработчики, чтобы синхронизировать свои базы данных, в то же время позволяя нескольким разработчикам (и клиентам / производителям контента) работать над одним проектом?

Есть 3 варианта из самых простых ->

1. Используйте только одну удаленную базу данных, к которой вы все подключаетесь с большим количеством резервных копий. Таким образом, вам нужно беспокоиться о файлах, а не о БД.

2. Используйте функции импорта и экспорта, встроенные в WordPress, и добавьте их в свой контроль версий прямо в корень wp (как в новой папке). Конечно, это займет дополнительные несколько минут, но это очень просто, и вы можете автоматизировать его, но что более важно, он станет частью контроля версий.

3. Используйте пользовательский скрипт обновления для версии фактической синхронизации базы данных. Честно говоря, я не знаю, как вы можете управлять этим с помощью git, потому что это всего лишь скрипт, и на самом деле не знаю, что происходит, я знаю, что есть сторонние инструменты, которые делают это коммерчески и бесплатно ( http: // www. liquibase.org/ ).

Если вам нужно полностью синхронизировать базы данных, т.е. Схема и данные, вы можете разработать систему управления версиями на основе резервных копий.

Или, если вы хотите сохранить данные в рабочем состоянии, но развить их схему, вы можете работать с пользовательским решением (версионным файлом со всеми изменениями схемы) или со стандартным решением, основанным на концепции migration. Вы можете найти много информации в этом потоке stackoverflow: Механизмы для отслеживания изменений схемы БД .

Извините, если это кажется невероятно очевидным, но если вам всем нужна одна и та же копия базы данных с одинаковой структурой, разве не имеет смысла иметь офисный / центральный сервер SQL и использовать его? Клонируйте его локально, если вам нужно экспериментировать, но сохраняйте его в качестве стандартного дефакто-стандарта и делайте резервные копии этого сервера и только этого сервера.

В противном случае, когда я работаю над групповым проектом, у нас есть собственные настройки с другим содержанием. Код заботится об обновлении и переносе табличных структур, и мы можем получить доступ к локальным установкам кода, работающего на наших машинах, через локальную сеть, поэтому нам не нужно обмениваться контентом.

Если мы вводим контент, мы запускаем его на тестовом сервере, который затем мы можем либо экспортировать и импортировать на работающий сервер, либо мы можем перейти непосредственно на производственный сервер, если в данный момент живого экземпляра не существует.

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