Comments
3 comments
-
One strategy could be to use different numbering for each team. You'd have to enable out of order migrations, but then you can achieve some separation between teams while still being able to move anyone's changes to any environment.
So for example, Team 1 will start their migrations at number 10000, Team 2 will start with 20000, and Team 3 will start with 30000. That gives you 10,000 migrations per team until you run out. At that point you should probably be doing a rebaseline anyway.
-
Thanks for the Suggestion. If we do that will the migration fail because the V## id out of Sync Team 1 will be on V12000__ and team 2 will be on V21000__ and team 3 V30003__ How will migration tool know about the team separation ?
Say if we set the Run out of order in Flyway. How will the migration tool run only the scripts of my team?
-
That's what enabling outOfOrder would do for you. Or at least, it will enable you to execute script 12000, then 30003, then 21002 without it throwing errors.
When it comes to actually deploying the changes, that might be more a question of your CI/CD rules. One team I work with has the standard that each deployment target has a branch (so a beta branch, a main/production branch) and any new migrations are first merged into those branches before deployment occurs.
Add comment
Please sign in to leave a comment.
We have a Sybase DB we are planning to use Flyway for ddl migration. We have 3 project teams working on one database. How will V##_ file name work in the migration folder when each team will moving to different environments at different times ?