0

We have a production system with a large DB (several hundred tables) and would like to begin using Flyway to manage DDL changes that occur through the dev cycle. However, the organization is setup in such a way that there are production DB changes that sometimes occur, mostly just data changes but possibly DDL, that will happen outside of a data migration tool. While this is obviously an organizational challenge, does this fact alone cripple a tool like Flyway? Or is there a workflow where Flyway could rebuild its indices on demand such that any out-of-band DB change like this is pulled in?

We'd love to use Flyway, but would need to integrate it incrementally until all teams using the system are trained/bought in.

Adam Hughes
  • 14,601
  • 12
  • 83
  • 122

2 Answers2

0

When introducing Flyway to a DB with existing data you will need to baseline Flyway to integrate with your existing data. See baseline.

For changes made after this, Flyway will only track and version changes made from its own migration scripts and not changes made externally to it. However, this does not mean you cannot use the two together, but you would need to be more aware of your database structure to avoid conflicts between your flyway migrations and external changes.

Barry
  • 369
  • 1
  • 6
  • There are some features in the paid versions of Flyway which can help monitor the 'drift' between your Flyway migrations and the real database structure which might help with you. https://flywaydb.org/documentation/command/check – Barry Aug 23 '22 at 08:06
  • Do you think it would hard to just regenerate the baseline every so often? Like every month? We're less concerned with having a perfect history of the DB and more that for any given sprint cycle, the changes we want to introduce are version controlled – Adam Hughes Aug 23 '22 at 14:14
  • @AdamHughes you can with Flyway Teams Edition https://flywaydb.org/reset-the-baseline-migration – Barry Aug 24 '22 at 08:15
0

Transactional data changes made to production shouldn't impact Flyway as these won't be versioned.

If you're referring to static data (eg lookup data) that you'd like Flyway to manage, then this isn't detected by Flyway (at least not today). If you discover that you have drift you'll need to add the changes as a new migration script using idempotent syntax to ensure that next time this runs against production it doesn't try to make the same changes again.

For out-of-band schema changes, The enterprise edition of Flyway has a drift check, so at least you'd be made aware of them. However, as for the data changes described above, you'll need to manually add these schema changes as an idempotent migration script.

David Atkinson
  • 5,759
  • 2
  • 28
  • 35