В настоящее время я работаю над проектом, в котором мы хотим оказать долгосрочную поддержку (LTS) для некоторых конкретных «версий LTS», которые мы выпустим в будущем.
Как следует из названия, мыхотите оказывать поддержку (исправления ошибок / исправления) для этих версий LTS в течение более длительного периода времени, не вынуждая клиента обновляться до последней версии.У каждого клиента есть своя локальная база данных.
Теперь проблема в том, что, если патч версии LTS содержит миграцию базы данных?Есть ли хороший пример / руководство / наилучшая практика, как справиться с этой ситуацией?
Мы используем подход доставки баз данных на основе миграции, аналогичный описанному здесь: https://enterprisecraftsmanship.com/2015/08/18/state-vs-migration-driven-database-delivery/
Пример Первая версия LTS "v1" с миграцией "M1" была выпущена и установлена для клиента "A".Последним последним выпуском является «v2.3» с миграцией «M16». Теперь необходима версия заплатки «v1.0.1» с миграцией «X» (которая изменяет тип столбца с int на bigint).
Проблема Клиент установил "v1.0.1" и теперь хочет обновить его до более новой версии.Одна идея состоит в том, что он может обновиться только до версии, которая содержит миграцию «X», чтобы код был совместим с базой данных.Но есть еще одна проблема:
В то время, когда была написана миграция «M2», миграции «X» не существовало.Что, если он (или некоторые из следующих миграций) несовместим с изменениями, выполненными миграцией "X"?
