Лучшая git система управления версиями mysql?

Я начал использовать git с небольшой командой разработчиков, которые приходят и идут по разным проектам; он работал достаточно хорошо, пока мы не начали работать с Wordpress. Поскольку Wordpress хранит много конфигураций в MySQL, мы решили, что нам нужно включить это в наши коммиты.

Это сработало достаточно хорошо (с использованием msyql дампа на pre-commits и нажатием сбрасываемого файла в mysql на пост-проверку), пока два человека не внесли изменения в плагины и не зафиксировали, затем все снова сломалось.

Я посмотрел на каждое решение, которое мог найти, и подумал, что Liquibase является самым близким вариантом, но не будет работать для нас. Это требует, чтобы вы указали схему в XML, что на самом деле невозможно, потому что мы используем плагины, которые автоматически вставляют данные/таблицы/изменения в БД.
Я планирую наложить на него щедрость через несколько дней, чтобы узнать, есть ли у кого-то решение "goldilocks":

Вопрос:
Есть ли способ контроля версий базы данных MySQL семантически (не используя diffs EDIT: это означает, что он не просто использует две версии и различает их, а вместо этого записывает фактические запросы, выполняемые последовательно, чтобы перейти от старой версии к текущей один) без требования файла сценария разработчика, и тот, который можно объединить с помощью git.

Я знаю, что я не могу быть единственным с такой проблемой, но, надеюсь, есть кто-то с решением?

ОТВЕТЫ

Ответ 1

Правильный способ обработки db-версий - это версия script, которая является только аддитивной. Из-за этого, он будет конфликтовать все время, так как каждая ветка будет добавляться к одному файлу. Ты хочешь это. Это заставляет разработчиков понимать, как изменения друг друга влияют на сохранение их данных. Rerere гарантирует, что вы разрешите конфликт только однажды. (см. мое сообщение в блоге, которое затрагивает разделение rerere: http://dymitruk.com/blog/2012/02/05/branch-per-feature/)

Удерживайте каждое изменение в условии if then, которое проверяет номер версии, изменяет схему или изменяет данные поиска или что-то еще, а затем увеличивает номер версии. Вы просто продолжаете делать это для каждого изменения.

в коде psuedo, вот пример.

if version table doesn't exist
  create version table with 1 column called "version"
  insert the a row with the value 0 for version
end if
-- now someone adds a feature that adds a members table
if version in version table is 0
  create table members with columns id, userid, passwordhash, salt
    with non-clustered index on the userid and pk on id
  update version to 1
end if
-- now some one adds a customers table
if version in version table is 1
  create table customers with columns id, fullname, address, phone
    with non-clustered index on fullname and phone and pk on id
  update version to 2
end if
-- and so on

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

Вопрос в том, как вы работаете в двух разных отраслях одновременно? То, что я делал в прошлом, только что развернуло новый экземпляр, который ограничен именем db именем ветки. Ваш файл конфигурации очищается (см. git smudge/clean), чтобы установить строку подключения для указания на новый или существующий экземпляр для этой ветки.

Если вы используете ORM, вы можете автоматизировать это поколение script, так как, например, nhibernate позволит вам экспортировать изменения графика, которые еще не отражены в схеме db, как sql script. Поэтому, если вы добавили сопоставление для класса клиента, NHibernate позволит вам сгенерировать создание таблицы script. Вы просто script добавили обертку if-then и автоматизировали в ветки функции.

Филиал интеграции и ветвь кандидата релиза имеют некоторые особые требования, которые потребуют очистки и повторного создания db, если вы сбросите эти ветки. Это легко сделать с помощью крючка, гарантируя, что новая ревизия git branch --contains старая ревизия. Если нет, протрите и восстановите.

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