Задать вопрос
@timintim
Планирую стать backend-разработчиком

Как обновлять структуру БД на рабочем сервере?

Как обновлять структуру БД на рабочем сервере? Сейчас все создания/удаления/изменения таблиц, колонок и т.д. выполняются вручную с помощью SSMS. Как организуется версионная миграция БД?
  • Вопрос задан
  • 72 просмотра
Подписаться 1 Простой Комментировать
Решения вопроса 1
denver14
@denver14
разработчик бэкенд и БД
Да, миграции, всё верно. Посмотрите в сторону Flyway или Liquibase. Вторым не пользовался, только читал, поэтому вкратце расскажу про Flyway. Он бесплатный в базовой функциональности, а её вполне хватает.

Миграции представляют собой SQL-файлы, названные по определённым правилам с указанием версии и краткого описания. Лично я вместо абстрактной версии использую текущие дату и время. Например, V20210601_1200__init.sql или V20210602_1015__alter_products.sql. Вручную файлы создавать скучно, я батник писал. Использование даты-времени позволяет создавать независимые миграции несколькими разработчиками параллельно и не особо обращать внимание на их порядок. Всё лежит в репозитории системы контроля версий вместе с остальным проектом.

При обновлении ветки кода (на стенде или на проде) запускаем flyway migrate. Он сверяет содержимое подкаталога с миграциями со своей служебной таблицей. Новые миграции применяются по очереди. К сожалению, здесь нет возможности отката миграции, как во фреймворках Yii или Rails.

Вкратце работа выглядит так:
  • В репозитории создаём подкаталог, скажем, db с конфигурационным файлом flyway.conf (точнее, конечно, в репозиторий идёт flyway.conf.example, а конкретный конфиг настраивается под каждый стенд БД локально)
  • Конфиг настраиваем на нужный экземпляр БД и подкаталог, где будут лежать файлы миграций, например db/migrations
  • Описываем текущее состояние в самой первой миграции, я её обычно зову init. Она должна с пустой схемы обеспечить накат структуры и справочников до текущего состояния. Иногда лучше миграции разбивать на две: структура отдельно, инсерты отдельно.
  • На тестовой базе выполняем flyway migrate и добиваемся того, чтобы миграция вкатывалась правильно. Откатывать придётся вручную, удаляя запись из служебной таблицы.
  • Если всё нормально, коммитим результаты, выполняем flyway migrate на проде и наслаждаемся :)


По хорошему, конечно, вызывать механизм мигрирования нужно не руками, этим должен заниматься CI/CD (например, Jenkins) по факту обновления соответствующей ветки репозитория. Но для пробы процесса пока этого достаточно.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
sarapinit
@sarapinit
Точу водой камень
Можете посмотреть, как это сделано в EntityFramework.
https://docs.microsoft.com/en-us/ef/core/managing-...
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы