Great show, thank you for hosting it! I have two questions really for the two of you, the first one is what kind of migration strategies do you use in production, particularly when you have multiple databases? I'm not sure what this is really called, but for lack of a better term, the 3 phase commit. First, create indexes/tables/columns; second, backfill data; and last, do destructive operations like deletes of columns. This allows us to have no downtime. I'm curious if you follow any particular strategy and if you end up having to write a lot of raw sql to perform these, or you're able to rely on ecto for the most part.
Second question is about seed data. What's you're approach to it? Currently, we've been keeping our seed data in migration files which makes destroying and setting up a dev environment easy to maintain and testable in some ways. Problems with this approach in a multi-database world happens when not all migrations have run through ecto, which made our seeds basically unrecoverable. Currently, I view them as two types of data, dev seeds and prod seeds. prod seeds should probably remain in the migrations but dev seeds should be managed. I'm curious to know what's worked for you guys or general thoughts on the topic. Thanks again!
Great show, thank you for hosting it! I have two questions really for the two of you, the first one is what kind of migration strategies do you use in production, particularly when you have multiple databases? I'm not sure what this is really called, but for lack of a better term, the 3 phase commit. First, create indexes/tables/columns; second, backfill data; and last, do destructive operations like deletes of columns. This allows us to have no downtime. I'm curious if you follow any particular strategy and if you end up having to write a lot of raw sql to perform these, or you're able to rely on ecto for the most part.
Second question is about seed data. What's you're approach to it? Currently, we've been keeping our seed data in migration files which makes destroying and setting up a dev environment easy to maintain and testable in some ways. Problems with this approach in a multi-database world happens when not all migrations have run through
ecto, which made our seeds basically unrecoverable. Currently, I view them as two types of data, dev seeds and prod seeds. prod seeds should probably remain in the migrations but dev seeds should be managed. I'm curious to know what's worked for you guys or general thoughts on the topic. Thanks again!