FlyWay migration strategy

Question

Currently on a project we use FlyWay, and we have a multiple environments, like: dev(local for developers), several instances of the application for QA guys, staging... And we have such workflow with tasks: in progress -> code review -> QA -> merge.

We faced with an issue: assume a developer, during working on a branch A, provided a new migration version, lets say V331, meanwhile a QA guy is doing qa on another branch, lets say B, on QA environment. It may happen that the qa environment already has version v331, because several developers may create the same version number on different branches at different time... More over qa switches between branches very often, and that is why qa database becomes messy, especially table schema_version, and it leads us that we have manually remove broken schema version, resolve old migrated version issues and then again launch migration process on an environment. How do you deal with multiple environments and flyway? Is there a best practice?

Answer 1

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

You can configure flyway to ignore the incremental value of versioning, with the outOfOrder config field: https://flywaydb.org/documentation/commandline/migrate

If you start naming your versions with issue numbers, you won't have overlapping version names and the merge won't care about missing sequential numbers or version names being lower then already merged items. How to use Flyway when working with feature branches

When not using issue trackers, you can figure out something else, where a new branch gets a higher subversion or anything like that.