Ответ 1
Если вы использовали подход "сущности первый" во время разработки, вам нужно будет сгенерировать исходную схему таким же образом для первого развертывания в реальном времени: это создаст первое создание script, используемое Flyway, и может также должен быть вторым ассоциированным script для заполнения справочных данных.
Вкратце, причины, по которым не удалось использовать hbm2ddl.auto после первого развертывания, заключаются в том, что create уничтожит существующие данные, а update недостаточно надежна, чтобы охватить все типы изменений схемы (как это звучит так, как вы уже знаете из этого SO-вопроса).
Flyway - очень полезный инструмент, но для этого требуется уровень дисциплины, который, возможно, не существовал во время разработки. При переходе от начального выпуска необходимо создать сценарии обновления базы данных для Flyway, которые эквивалентны изменениям, внесенным в объекты с момента последней версии. Существуют инструменты (например, различные коммерческие продукты из Redgate), которые могут помочь здесь: они пытаются "разделить" две схемы и сгенерировать схему и/или сценарии обновления данных для получения из базы данных A в базу данных B. Но, по моему опыту, ни один из них не идеален, и они не вполне достигают святого грааля, позволяющего полностью автоматизировать подход.
Возможно, наилучшим способом является ручной подход "как вы", чтобы гарантировать, что сценарии неразрушающего обновления будут привязаны к контролю источника, когда будет произведено изменение сущности, влияющее на схему или справочные данные, - но, как уже упоминалось, это потребует определенной дисциплины и/или документированных процессов для всех членов команды.