Question

We have recently moved to using feature branches for each story we work on. These are as independent as possible, and our project manager then decides which stories will make up a release. This means that we do not know the exact order in which stories will go into production initially.

Is there a standard way of dealing with this in Flyway? I have read the FAQ which discusses how the change to the production database will be linear, which is correct. However I’m not sure how team members would decide what version numbers to give their migrations while they are working on their feature branch. Also we would need to manually renames the migration files when we merge to our integration branch and master before the release.

Answer 1

You cannot have migration scrtipts with the same version number as you will get:

Found more than one migration with version ‘x.y.z’ (Offenders: SQL …)

Here is a workaround I suggest: multiple developers are working on the same version, say 1.0 but on different features. I guess you are using some issue tracker that adds ids to each issue, like FOO-16. When a developer works on that issue, the migration script is called V1.0.16__my_greatest_feature.sql. This way (assuming each feature/branch has its own issue) there are no collisions.

Also I am assuming that database migration scripts are independnt and non-overlapping, but if this is not the case you’ll have problems while merging everything to a stable release.

So in a stable release you have several migration scripts with gaps, e.g: V1.0.16, V1.0.27, V1.0.101 (if FOO-16, FOO-27 and FOO-101 were chosen) – Flyway won’t care. All the features that didn’t make it to a stable release 1.0 (e.g. V1.0.35) should be renamed to target next major release (e.g. V1.1.35).