Flyway migration with single schema and multiple projects

Question

I have a question related to Flyway DB Migrations. How to generally manage multiple projects (microservices) dealing with the same DB schema. The Flyway migration scripts in each of the project does not allow to start if it is modified by the other project. Do they have any documentation or best practices on the same?

Answer 1

We are in the process of doing this. We have one central project that manages the schema creation/management, and other projects handle their own function creations all via their own flyway versioning. This is done by changing the name of the table that those other projects check their schema version against, and setting baseline on migrate to true. We are using spring/flyway-db configuration so this was simply adding the following to application.properties for each project in addition to the first.

flyway.baselineOnMigrate=true
flyway.table=schema_version_*<some_other_identifier>*

I know your question did not specify a spring configuration explicitly, but I believe this can be configured not matter how you are using flyway. I wanted to post an answer as when I was googling the question myself, your SO question was the top result, and I figured my answer might help someone down the track.

Answer 2

For what it is worth, this is what we did. Since the schema was shared by multiple projects we had the schema managed by a single project whose task was to maintain said schema. Centralizing schema creation and maintenance had other benefits in that we had single locus of change. We needn't scan several projects for changes.

I honestly think this is the best solution. I don't believe flyway has inter-project schema dependency management.

Answer 3

I have faced same issue, because I was working with 2-3 micro services, So what I did is as below example, running in following sequence

micro-service-1 ( which required migration )
micro-service-2
micro-service-3 ( which required migration )

So I created flyway migration v1__description.sql in micro-service-1 and then in micro-service-3 I created v1_2__description.sql because it is at 3rd in sequence of running projects, this is my release version 1, which are having 2 migration with version 1 and 1.2

micro-service-1 ( V1_description.sql )
micro-service-2 // if in future it reuires migration then we can use, V<<currentVersion>>_1__description.sql
micro-service-3 ( V1_2_description.sql )

Answer 4

if any one using the Play frame work this problem can be tackle with independent flyway history tables for each microservice mean every mircoservice has its own flyway history table with name according to service. this ll create flyway table for each service add these properties in conf file for changing the flyway table name.

db.default.migration.table=microservice1    for 1 mircoservice
db.default.migration.table=microservice2    for 2 mircoservice

add this property in every microservice conf file this is only for play frame work