3 ms·
Interesting. What happens if your schema is rolled back (e.g., to remove a new column), but your binary isn’t? Or is the idea to always deploy schema rollbacks
by Cyph0n 2y ago
Interesting. What happens if your schema is rolled back (e.g., to remove a new column), but your binary isn’t? Or is the idea to always deploy schema rollbacks alongside your binary?
Edit: Also, curious about how this would work with a progressive schema rollout across environments - e.g., staging vs. prod DB. Do you need to “wait” for your new column to hit prod before you can use it in unit tests?
- magicalhippo 2y agoOr just don't do schema rollbacks. We allow customers to run old versions if our program against an upgraded database, and to do that we just don't do destructive schema changes.
- Cyph0n 2y agoI suppose that’s one option. But sometimes you want the ability to rollback on bad or potentially destructive schema changes.
- taberiand 2y agoAt a basic level - database migrations must be backwards compatible at least with the previous version, and they go out before the service update is deployed. Unit tests don't run direct against prod usually, but regardless they would be run after migrations to a database of (production schema+migrations). Each environment - dev, test, staging, prod has its own db. Even spinning up an ephemeral db per test is possible, and easy with containers. YMMV as system complexity increases, but by then there should be whole team(s) managing the issue
- deleted 2y ago[deleted]