Синхронизация базы данных WordPress между несколькими разработчиками с использованием Git

Question

Синхронизация базы данных WordPress между несколькими разработчиками с использованием Git

20 мая 2012 г., 21:20:21

Просмотры: 17.2K

Голосов: 38

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

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

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

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

Philip Downer

952

база данных git стратегия разработки

Все ответы на вопрос

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

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

grosshat

86

20 мая 2012 г. 22:37:59

Комментарии

Также простой вопрос здесь http://stackoverflow.com/questions/825787/how-to-automate-migration-schema-and-data-for-php-mysql-application

grm

22 мая 2012 г. 23:28:48

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

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

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

// Если в какой-то момент вам нужно разделить данные продакшена, теста и работы в процессе, просто используйте ветки продакшена, теста и разработки в вашем репозитории.

Tom J Nowell

60.7K

20 мая 2012 г. 23:47:05

Для тех, кто считает вышеописанные решения недостаточно простыми, отличным платным плагином является WP Migrate DB Pro.

Он позволяет передавать базы данных между экземплярами WordPress. Хотя он не предлагает систему управления базами данных, подобную git, но если у вас есть центральный staging-сервер, который является "источником истины" для баз данных и где должны вноситься изменения, он работает превосходно.

(Устаревшая рекомендация ниже - спасибо Elmar за комментарий)

Или вы можете рассмотреть Version Press, который заявляет о предоставлении git-подобного управления файлами и базами данных. Я лично не использовал этот плагин, но следил за ним некоторое время, и он до сих пор существует.

Jake

250

14 апр. 2021 г. 06:34:56

Комментарии

К сожалению, разработка Version Press больше не ведётся...

Elmar Zander

1 сент. 2021 г. 18:31:41

Спасибо @ElmarZander, я обновил свой ответ.

Jake

2 сент. 2021 г. 06:46:29

Wyck 18K · Accepted Answer · 2012-05-21T02:02:11Z

Есть 3 варианта, от самого простого -->

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