Jeśli w trakcie opracowywania zastosowałeś podejście "istoty pierwsze", musisz wygenerować początkowy schemat w taki sam sposób dla pierwszego wdrożenia na żywo: stworzy to pierwszy skrypt kreacji używany przez Flyway, a także może musi być drugim skojarzonym skryptem do zapełniania danych referencyjnych.
W skrócie, przyczyny nie są w stanie używać hbm2ddl.auto po pierwszej misji jest to, że create zniszczy istniejące dane i update nie jest na tyle wiarygodne, aby objąć wszystkie rodzaje zmian schematu (jak to brzmi jak może już wiem od this SO question).
Flyway to bardzo przydatne narzędzie, ale wymaga pewnego poziomu dyscypliny, który mógł nie istnieć w trakcie rozwoju. Przy przejściu od pierwszego wydania należy przygotować skrypty aktualizacji bazy danych dla Flywaya, które są odpowiednikiem zmian wprowadzonych w jednostkach od ostatniej wersji. Istnieją narzędzia (np. Różne komercyjne produkty od Redgate), które mogą pomóc tutaj: Te próby "zmiany" dwóch schematów i generowania schematów i/lub skryptów aktualizacji danych dla uzyskania z bazy danych A do bazy danych B. Ale z mojego doświadczenia, żaden z nich są doskonałe i nie docierają do świętego Graala, umożliwiając całkowicie zautomatyzowane podejście.
Prawdopodobnie najlepszym sposobem jest ręczne podejście typu "jak to działa", aby zapewnić, że nieinwazyjne skrypty aktualizacji są zobowiązane do kontroli kodu źródłowego, gdy wprowadzana jest zmiana jednostki wpływająca na schemat lub dane referencyjne - ale jak już wspomniano, będzie to wymagało dyscypliny i/lub udokumentowanych procesów dla wszystkich członków zespołu.
Możesz również znaleźć Liquibase pomocne. Wspominam o tym, aby nie wysuwać argumentu Flywaya przeciwko Liquibase, ale dlatego, że Liquibase zajmuje się tym szczególnym przypadkiem użycia jako koncepcja pierwszej klasy. Zobacz w szczególności http://www.liquibase.org/documentation/generating_changelogs.html. –