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

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

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

Я предлагаю обходной путь: несколько разработчиков работают над одной и той же версией, скажем 1.0, но над разными функциями. Я предполагаю, что вы используете средство отслеживания проблем, которое добавляет идентификаторы к каждой проблеме, например FOO-16. Когда разработчик работает над этой проблемой, сценарий миграции называется 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).

Лучший способ, который я видел, чтобы преодолеть проблемы с версией между ветвями, чтобы включить 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 также обрабатывает префиксы временных меток как целые числа. Это означает, что если вы изначально начали работать с Flyway, используя целые числа, вы все равно можете переключиться на временные метки в любой момент. Поскольку временные метки - это просто очень большие целые числа, первая миграция с префиксом временной метки будет просто применена после последней миграции с целочисленным префиксом.

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

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