Подтвердить что ты не робот

Как использовать Flyway при работе с ветвями функций

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

Есть ли стандартный способ справиться с этим в Flyway? Я прочитал FAQ, в котором обсуждается, как изменение в производственной базе данных будет линейным, что верно. Однако я не уверен, как члены команды решат, какие номера версий будут давать свои миграции, пока они работают над своей функциональной ветвью. Также нам нужно будет вручную переименовывать файлы миграции, когда мы сливаемся с нашей веткой интеграции и мастером перед выпуском.

4b9b3361

ОТВЕТЫ

Ответ 1

У вас не может быть сценариев миграции с тем же номером версии, что и вы:

Найдено более одной миграции с версией "x.y.z" (Нарушители: SQL...)

Вот обходной путь, который я предлагаю: несколько разработчиков работают над одной и той же версией, скажем 1.0, но по разным функциям. Я предполагаю, что вы используете какой-то трекер, который добавляет идентификаторы для каждой проблемы, например FOO-16. Когда разработчик работает над этой проблемой, миграция script называется V1.0.16__my_greatest_feature.sql. Таким образом (при условии, что каждая функция/ветвь имеет свою собственную проблему), не происходит столкновений.

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

Таким образом, в стабильном выпуске у вас есть несколько сценариев миграции с пробелами, например: V1.0.16, V1.0.27, V1.0.101 (если выбраны FOO-16, FOO-27 и FOO-101) - Flyway не будет забота. Все функции, которые не привели к стабильному выпуску 1.0 (например, V1.0.35), должны быть переименованы в целевой следующий основной выпуск (например, V1.1.35).

Ответ 2

Лучший способ, которым я видел преодоление проблем с версиями между ветвями, чтобы включить outOfOrder, и использовать временную метку в качестве номера версии

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

  • 1.0.0.1__add_customers_table.sql
  • 1.0.0.2__add_email_address_column_to_customers_table.sql
  • 1.0.0.3__add_orders_table_with_reference_to_customer_table.sql

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

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

  • 1.0.0.20130704144750766__add_customers_table.sql
  • 1.0.0.20130706132142244__add_email_address_column_to_customers_table.sql
  • 1.0.0.20130706151409978__add_orders_table_with_reference_to_customer_table.sql

Шаблон временной метки выше точно до миллисекунды. В то время как очень точная метка времени может привести к трудно читаемым префиксам, чем точнее ваш префикс, тем менее вероятным будет столкновение.

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

Кроме того, обратите внимание, что Flyway также обрабатывает префикс timestamp как целые числа. Это означает, что если вы первоначально начали работать с Flyway с помощью целых чисел, вы все равно можете переключиться на отметки времени в любой момент. Поскольку временные метки представляют собой очень большие целые числа, первая миграция с префиксом с меткой времени просто применяется после последнего переноса с префиксом целых чисел.

Взято отсюда и слегка изменено: http://www.jeremyjarrell.com/using-flyway-db-with-distributed-version-control/

Ответ 3

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