Strategy for Flyway Data migration

26reds

We have a product which caters to different Market segments, i.e. Banking, Utilities etc.

When we do a install for the product, we need to make sure common data i.e. table DDL's and any system configuration data needed across domain is stored together. Any domain specific data is managed in a different folder. For example,

We use V1.1__ - V1.x__ for all base configuration i.e. DDL's and common system configuration.
We use V2.1__ - V2.x__ for all configuration data specific to Banking Domain
We use V3.1__ - V3.x__ for all configuration data specific to Utilities

And then we have V4.1__ - V4.x , V5.1__ - V5.x to manage any client specific day 0 configuration/transactional data.

Issue we are facing is once a release is installed, It runs data from for example, V1, V2 and V4. Now to deploy a subsequent release, we will have additions in the V1.x series as new database might be added as part of the release.

When we try to do a flyway migrate, we have an error because the scripts are not in order. i.e. V4.x has executed and it cannot execute V1.x scripts. We are working around this by setting the flyway.outOfOrder property, but we would like to avoid using this property.

Is there any better way to manage the script migration for this use case?

David Atkinson

What is the reason for trying to avoid outOfOrder?

I think what may serve your needs better are Deploy Rules (a Flyway Teams feature), where you can assign specific scripts to specific target environments. This would mean not having to manage the changes in separate folders. When you create a script you simply specify which environments the script should be run against.