Как обеспечить консистентность базы данных при переходе между ветками git?

Question

[Дмитрий]

Есть проект, в котором используется миграция базы данных (а где не используется? ;)).
Подскажите, как (с помощью чего) обеспечить правильную структуру тестовой БД при любом git checkout?
Понятно, что вопрос не связан с миграцией как с таковой потому, что делать migrate:rollback нельзя - могут удалиться какие-то столбцы и при возврате они не будут заполнены информацией.
Как лучше поступить?

Comments

[Максим]

А ветки длинные по времени разработки? Т.е. если постоянно идет ветвление и срок жизни ветки меньше месяца, то это один путь, если же ветки живут по несколько месяцев, то другой

[Дмитрий]

Думаю что правильный путь тот, где время жизни ветки не играет роли.
Речь идет о простом переключении между ветками. Это с одинаковой вероятность может понадобиться/не понадобиться в короткой/длинной ветке.

[Владимир]

можно положить скрипты инициализации базы в git, и для переключения бранчи использовать скрипт который будет делать git checkout + DB reset + DB setup. После переключения у вас будут скрипты актуальные для данной бранчи останется лишь удалить существующую базу. Если нет возможности пересоздать базу с нуля или полностью ее почистить придется хранить в git еще и скрипты очистки базы. В скрипте для git checkout поменяется порядок: DB reset + git checkout + DB setup (т.е. удалили структуру в ветке А, переключились на ветку Б, проинициализировали БД скриптами из ветки Б).

p.s. если нужно заполнять базу какими-то данными то надо обновить главный скрипт

[Дмитрий]

Спасибо, Владимир!
Вам лучше было оформить это в виде ответа. В целом, все остальные участники предлагают то же самое (migration + seed).

Answer 1

[Александр Кузнецов]

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

Советую глянуть в это сторону.

В противном случае, вы либо будете тратить много времени на приведение БД к нужному виду, либо наплодите на dev-машине кучу баз под соответствующие ветки - что тоже так себе решение.

Comments

[Дмитрий]

Я уже использую docker, но держу базу на хосте.
Да, держать базу в контейнере, сидировать данные и перезапускать контейнер - это хорошая мысль!
Спасибо!

[Dmitry MiksIr]

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

Answer 2

[cicatrix]

В Entity Framework можно управлять миграциями и как следствие - версионировать базу данных.
Правда, прикрутить её к уже готовому проекту - отдельная песня.

Comments

[Decadal]

Это вы про ADO.NET? Я бы посмотрел как вы его прикрутите к Laravel

[Александр Кузнецов]

В Doctrine ORM с этим все точно так же - там есть пакет для полноценной работы с миграциями

Answer 3

[RuJet]

В Drupal 7 можно сделать /update.php и накатятся изменения в структуре БД. Правда не все и не всегда :)