|
|
|
|
|
|
by rafaelquicdb
255 days ago
|
|
|
Interesting, I didn't know about liquibase, thanks for sharing! How about the data itself, do you usually seed it for local development, or PR/staging environments? Or do you get production subset for example? And if you do, do you deidentify the prod data to use in the non-production environments? Trying to understand any pain points related to that the product development workflow (i.e. local dev, PR, QA, demo, etc.). Thank you! |
|
|
In local dev you're usually starting from a blank database and sequentially executing the entire history of changes for the database, so it's not prone to breakage unless that sequence changes, or you're updating an already-builty database but you've made manual changes that are not compatible with the scripted changes.
For shared databases Liquibase supports rollbacks which let you undo whatever you just did as long as you have defined that process. Sequelize does too. Basically your changeset or migration script define how to perform the change and how to undo it.
In shared databases there's two risks I've encountered, one is that data in that db that isn't present in local dev will need wrangling before a change can be executed, the other is that tables and columns can be dependencies of views and stored procedures and the like which may be managed separately so you're balancing the defined changeset against external/unknown changes.