3 ms·
CLI tools like Flyway still play a critical role nowadays. However, they show their ages facing the arising infra complexity and demanding collaboration require
by tianzhou 4y ago
CLI tools like Flyway still play a critical role nowadays. However, they show their ages facing the arising infra complexity and demanding collaboration requirements.
Teams need GitLab / GitHub to collaborate instead of relying on Git merely.
It's not about pretty UI and more about UX / DX around dealing with database migrations like how GitLab / GitHub deals with code changes.
- chrisjc 4y agoIt took me a few minutes to really understand what you're getting at, but I think I understand. And Flyway can be used in conjunction with GitLab/GitHub to achieve the same thing, but it's still plagued with all of the issues you can probably imagine, especially if your DB doesn't support transactional DDLs. I agree about how these database migration (i hate this name) tools are starting to show their age, but when it comes to read/write schemas there doesn't seem to be many options. If you're wondering why I qualified the above statement with "read/write", there is an alternative way of managing read schemas that has a lot in common with any other sort of artifact management lifecycle that we have become accustomed to. Every source change that results in a CI/CD activity leads to an entirely new instance of the schema being built out. Then it's just a matter of hot swapping the new schema (`ALTER SCHEMA ACME SWAP WITH ACME_V2_0 RENAME TO ACME_V1_9_OLD`) or just having your consumers update their connection configurations to point to the new schema (schema=ACME_V2_0). Rollback is just unswap, or reverting your app's connection config (or maybe the software artifact should be hard tied to the schema anyways?). The whole process of using a migration tool to alter individual parts of a live schema one piece at a time, updating/data, etc... and rollback if necessary, is extremely complex and an incredible nightmare to deal with, esp if these tools are in the hands of app developers with limited DBA experience. Imagine that if instead of building new code artifacts (jar, zip, etc) we just resorted to taking the latest one, modifying it, and then saved it (overwrite). And then when you experience an issue and have to rollback, you have to undo everything mentioned above.