How to manage flyway migration across multiple apps sharing same database

user_1900290 0
Viewed 100

How to manage flyway migration across multiple apps sharing same database.

  1. Service-A based on Spring Boot, points to Database-A
  2. Service-B based on Spring Boot, points to Database-A
  3. Service-C based on Spring Boot, points to Database-A

How should we manage flyway migration scripts

  1. Should we have a separate repository for managing the database scripts
  2. Since each of the services are launched as docker containers and we don't want the migration to be triggered on each of the container
  3. What would be the preferred way to manage the flyway migration scripts, so that it allows us to rollback or promote changes in a CI/CD environment
flyway jenkins-pipeline spring-boot jenkins
2 Answers

There is arguably nothing stopping you from doing this. If all three services are using different schemas on the same database instance, you can set the defaultSchema and schemas properties for each services flyway configuration to insure the schema history table is within each services respective schema and there wont be any overlap.

However, if your are using the same schemas for each service, I've seen in previous projects that versioning can trip systems up.

For example: If each service manages its own migration script versions, this can cause conflicts. I.E. If service A has a V1, V2 and V3 script and so does service B then flyway will throw a checksum error as it will detect the content of V1 etc has changed when migrating service B after service A. However, this can be over come with careful versioning of your migration scripts. For ease I'd suggest using a versioning system which implicitly creates a temporal order, for example V2022.08.26.10.01__your_script.sql.

Alternatively, you could use the out of order as well to keep better control of your migration order

user_163987660

You can have a module containing all migration scripts, which can be added as a dependency by all services (A, B and C in your example). Once you have that in place, only one of the services should run the migrations e.g, service A and the other services (B and C) should just validate the schema. As an advantage, if you are running integration tests on your services, they can run flyway independently at test time or on your CI/CD pipeline to execute the test. Even for local development, Flyway can be activated.

Unfortunately, this introduces a slight dependency on the deployment order of your services, they can still be deployed in any order, but till the service in charge of the migration's executions does its job, the other will be unhealthy. If you use some kind of Blue/Green deployment style, silos or similar, this should not be a problem, but just something to consider.

If you decided to try something like that, you just need to overwrite the Flyway migration phase and leave the migration method empty while the validation still operative. I think you need to look at FlywayMigrationStrategy, but I haven't done it in some time, check yourself first.

user_98157390
Related