FlyWay Migration Strategy

Question

We are currently using FlyWay in the project, and we have several environments, such as dev (local for developers), several application instances for QA pairs, setting ... And we have such a workflow with tasks: in the process → overview code -> QA -> merge .

We ran into a problem: suppose the developer, while working on branch A, provided a new version of migration, say, V331, while the guy QA does qa on another branch, say, B , in the QA environment. It may happen that the qa environment already has version v331, because several developers can create the same version number in different branches at different times ... Moreover, qa very often switches between branches, and that’s why the qa database becomes messy, especially the schema_version table , and this leads us to manually delete the broken version of the scheme, fix the old problems with the migrated version, and then start the migration process in the environment again. How do you feel about multiple environments and spans? Is there any best practice?

Answer 1

There is a way, not sure if it suits your needs.

You can configure flyway to ignore the incremental version value, with the outOfOrderconfig field : https://flywaydb.org/documentation/commandline/migrate

If you start calling your versions release numbers, you will not have matching version names, and the merge will not take care that the missing consecutive numbers or version names are lower than the merged elements. How to use Flyway when working with function branches

If you don't use trackers with problems, you might find something else where the new branch gets higher subversion or something like that.