4 ms·

I'd spawn a new DB for that instance too. It can still go a long way to give you a look at how your application worked in the past.

wokwokwok 4y ago
Am I mistaken in thinking that’s totally ridiculous? Let’s charitably say you can run your app with a 1GB cut down snapshot of production. You’re going to do what, save a snapshot of the database for every commit? Every schema migration? …and then provision that up in a running database server… which is notoriously not container friendly… ? It doesn’t sound very plausible to me. Our database is ~1TB, and the app runs with maybe a 10GB cut down version of it, which is a pain in the ass to deal with, just for example, for local dev environments. I agree with the parent post; it’s cute, but I can’t imagine historical per commit deployments being useful for me, honestly.
- crabmusket 4y ago
  > Let’s charitably say you can run your app with a 1GB cut down snapshot of production. Plenty of apps can run from an empty database, if the data storage is focused on resources you, the user, have created for yourself. But I imagine that people with their heads in the future are imagining you'll use one of these new database startups (the names escape me) to manage snapshots, seeding from anonymised production data, etc.
- dismantlethesun 4y ago
  Historical deployments would be useful to me because our app rarely has database schema changes in the hot path. Most of our effort is in user experience and post processing. It would be nice to compare the experience of todays version with one from 6 months or 1 year ago for certain components. We do already have a historical design storyboard but seeing it with live data would be more useful.
- erikpukinskis 4y ago
  What do you need production data for? Just fire up a fresh DB with some sensible default fixtures. Or pause an integration test mid-way. Or call some factories from the REPL. The last thing in the world I want to do development with is production data. Production data is the data of last resort when nothing else can repro.
- o_m 4y ago
  You can use a seeder script to generate fake data. If you are deploying something that is not production you shouldn't use real data, especially if it contains personal data.

wokwokwok 4y ago

Am I mistaken in thinking that’s totally ridiculous? Let’s charitably say you can run your app with a 1GB cut down snapshot of production. You’re going to do what, save a snapshot of the database for every commit? Every schema migration? …and then provision that up in a running database server… which is notoriously not container friendly… ? It doesn’t sound very plausible to me. Our database is ~1TB, and the app runs with maybe a 10GB cut down version of it, which is a pain in the ass to deal with, just for example, for local dev environments. I agree with the parent post; it’s cute, but I can’t imagine historical per commit deployments being useful for me, honestly.

crabmusket 4y ago
> Let’s charitably say you can run your app with a 1GB cut down snapshot of production. Plenty of apps can run from an empty database, if the data storage is focused on resources you, the user, have created for yourself. But I imagine that people with their heads in the future are imagining you'll use one of these new database startups (the names escape me) to manage snapshots, seeding from anonymised production data, etc.
dismantlethesun 4y ago
Historical deployments would be useful to me because our app rarely has database schema changes in the hot path. Most of our effort is in user experience and post processing. It would be nice to compare the experience of todays version with one from 6 months or 1 year ago for certain components. We do already have a historical design storyboard but seeing it with live data would be more useful.
erikpukinskis 4y ago
What do you need production data for? Just fire up a fresh DB with some sensible default fixtures. Or pause an integration test mid-way. Or call some factories from the REPL. The last thing in the world I want to do development with is production data. Production data is the data of last resort when nothing else can repro.
o_m 4y ago
You can use a seeder script to generate fake data. If you are deploying something that is not production you shouldn't use real data, especially if it contains personal data.