1

Imagine I'm maintaining a separate branch for Production releases and a separate one for Dev environment (Master branch). Master branch is always ahead of the Production branch and suppose I want to do a hot fix on production branch. Flyway is used for DB migration and Flyway versions of each branch would be as follows.

Production branch

V_1
.
.
V_634
V_635

Master branch

V_1
.
.
V_634
V_635
V_636
V_637

As per this link I was able to overcome the initial issue that I was facing which Flyway give out for contradicting version numbers. And after this and couple of changes in dev environment, each branch would look like follows.

Production branch

V_1
.
.
V_634
V_635
V_635.1 (hotfix is applied here)

Master branch

V_1
.
.
V_634
V_635
V_636
V_637
V_638 (hotfix is applied here)
V_639

Now when imagine I need to do a production release after V_639. So when I do the release, the change is the V_638 would have already been applied in production with the hotfix. So it gives an error. Anyone knows how to manage this?

Thathsara Radeeka
  • 21
  • 3

1 Answers1

0

If you run V__635.1 on production, that's now how that deployment was run. You can't add the same code to V__638. That's why it's failing. Instead, you need to merge the prod into your main branch so that 635.1 is there. That will require rebuilding the development database so that 635.1 is included now.

BTW, this is solved through Cherry Picking in the Teams (paid) version of Flyway. You can deploy stuff out of order. So you'd be able to deploy 635.1 to prod, then add it to your main branch, and deploy just 635.1 to development, and everything would be good from there.

Grant Fritchey
  • 2,645
  • 19
  • 21
  • Thanks for your input. The issue with above option 1 is, we have a highly volatile dev environment so by the time V_653.1 is applied, dev environment might be ahead of a considerable amount of commits, so merging master and production after V_635_1 would mean a repetition of these commits. – Thathsara Radeeka Oct 20 '22 at 04:22
  • As for the option 2, we have multiple developers working with the same project, so enabling out of order would result in conflicting migrations. So it'll be better to keep out of order disabled. – Thathsara Radeeka Oct 20 '22 at 04:26
  • I'd still go with what you do to prod is the truth, not dev. Does that require some planning & discipline? Yeah. But it's somewhat the nature of databases and deployments. There so much dependency on the order of operations, it simply can't be avoided. – Grant Fritchey Oct 20 '22 at 12:17