Интеграция Flyway в существующую базу данных - PullRequest
1 голос
/ 05 августа 2020

Мы не использовали Flyway с самого начала нашего проекта. Мы находимся на продвинутой стадии разработки. Экспертная оценка предложила использовать Flyway в нашем проекте.

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

Как лучше правильно реализовать Flyway? Требования:

  1. В среде разработки нет необходимости изменять уже существующую схему. Но все новые скрипты должны выполняться с использованием Flyway.

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

  3. Когда мы выполняем миграцию в совершенно новую среду (UAT, Production et c) вся схема должна быть создана автоматически с помощью Flyway.

Из документации я понял:

  1. Сделайте резервную копию разработки схемы (как DDL, так и DML) в виде файлов сценариев SQL, укажите имя файла, например V1_0_1__initial. sql.
  2. Очистите базу данных разработки, используя "flyway clean".
  3. Базовый уровень разработки database "flyway baseline -baselineversion = 1.0.0"
  4. Теперь выполните команду «flyway migrate», которая применит SQL файл сценария V1_0_1__initial. sql.
  5. Все новые сценарии должны быть написано с более высокими номерами версий (например, V2_0_1__account_table. sql)

Это правильный способ или есть лучший способ сделать это?

Проблема i s, что у меня есть тестовая база данных, в которой у нас другой набор данных (данные в Dev и test разные, и я хотел бы сохранить данные такими, как они есть в обеих средах). Если да, то хорошо ли разделять DDL и DML в разных файлах сценария, когда мы берем их из среды Dev и применяем их отдельно в каждой среде? При необходимости DML можно добавить вручную; но немного запуталась, правильно ли я поступаю.

Заранее спасибо.

1 Ответ

1 голос
/ 06 августа 2020

Итак, на самом деле здесь есть два вопроса. Управление данными и управление пролетным путем.

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

Вы можете реализовать Flyway в существующем проекте, да . Ключевым моментом является установление базовой линии. Вам не нужно делать все шаги, описанные выше. Допустим, у вас есть существующая база данных. Вы должны получить сценарий, определяющий эту базу данных. Этот единственный сценарий должен включать весь соответствующий DDL (и, если хотите, DML). Назовите его в соответствии со стандартами Flyway. Что-то вроде V1.0__Baseline. sql.

После этого все, что вам нужно сделать, это запустить:

flyway baseline

Это установит sh существующую базу кода в качестве начала точка. Оттуда вам просто нужно создать сценарии в соответствии со стандартом именования: V1.1xxx V2.0xxx V53000.1xxx. И запустите

flyway migrate

, чтобы внедрить соответствующие изменения.

Единственное предостережение в том, что, как указано в документации, вы должны убедиться, что все ваши базы данных соответствуют этой версии V1.0, которую вы ' воссоздание и разметка в качестве базовой линии. Любое отклонение вызовет ошибки по мере того, как вы вводите новые изменения и переносите их на место. Если у вас есть совпадающие базовые точки, вы сможете без проблем работать с разными данными в разных средах.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...