как правильно изменить структуру базы данных при работе с Flyway?

Question

Например, у меня есть сценарий V1__InitScript.sql с запросом:

create table if not exists users
(
  guid varchar(36) not null primary key,
  name varchar(255) not null,
  description varchar(500)
);

Я запускаю мое приложение на чистой БД и выполняю этот сценарий.Теперь у меня есть пустая таблица с именем users и 3 столбцами.Я начинаю работу, и мне нужно добавить один столбец, например age.что мне делать?

1) Я могу добавить этот столбец в таблицу.И после этого добавьте этот запрос к V2__Add_column.sql.Но когда я запускаю приложение flyway, попробуйте сделать этот сценарий V2, потому что он не существует в таблице flyway_schema_history.

2) Когда я хочу добавить столбец, я немедленно добавляю его с помощью flyway.Но когда я занимаюсь активной разработкой, я часто могу изменить данные.Таким образом, я должен запускать flyway для каждого изменения?

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

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

Answer 1

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

При использовании Spring Boot убедитесь, что Flyway запускается автоматически при запуске ApplicationContext.Это обеспечит автоматическую миграцию базы данных как в приложении, так и при запуске модульного теста.

Для быстрой итерации в dev вы можете активировать режим Flyway cleanOnValidationError.Таким образом, каждый раз, когда вы изменяете свой последний скрипт миграции, который вы еще не зафиксировали, его контрольная сумма будет изменяться, что, в свою очередь, приведет к сбою проверки Flyway, что затем с этим свойством вызовет очистку базы данных dev, которая будетсразу же после миграции, чтобы воссоздать его полностью в соответствии с последней версией ваших сценариев.

Answer 2

Для меня наиболее удобным способом было иметь базу данных разработки, которая не заполняется Flyway и может быть изменена вручную в любое время, а также некоторую базу данных для тестирования, которая заполняется только Flyway и никогда не используется вручную и используется длялюбые цели тестирования (включая автоматизацию тестирования).И, конечно же, Flyway следует использовать в производстве.

Таким образом, вы можете свободно изменять базу данных во время разработки и при этом иметь все преимущества Flyway для развертывания.