Every software product I've ever built always has this same problem. Sales, marketing / product need a repeatable demo account populated with best case scenario data that doesn't take manual reset and doesn't have any side effects. I was listening to this episode of the Re-work podcast from Basecamp and it was good to know that I'm not totally crazy in this being a pain point.
💬🙏 comment below — how are you solving this?
I would love to know, don't limit answers to Rails! I'm sure we can be inspired based on whatever framework people are in.
Our Current solution — very "Rails Specific"
I use Rails fixtures and pre-load those fixtures in a bin/setup script. If you take your time to pre-populate all this fixture data it works really well. You've got that data for testing (Which is usually a win) and then it's easy to set up staging or localhost to just reset back to this state with a simple command.
However — especially with ActionText and ActiveStorage it gets clunky and you end up with these huge fixture files. I have found some solutions to limit the pain here, you can pull down production data and then write it to fixtures, then update it.
Other Misc Rails Thoughts / Tips
I've recently learned you can do this quasi-inheritance thing in your fixture files to DRY them up. And of course, you can write ERB in fixtures. (Things like Faker can help this) but even with all this, there's got to be a better way.
Again — would love to hear from the Dev.to community
- How do you deal with "Demo" account data?
- How does your marketing and sales team are well supported on this? What if they need to make changes or updates?
- How do you keep this whole thing from not being such a pain in the ass?
- How do you keep this in sync with new feature rollouts?
Top comments (7)
I'm sure there's lots of solutions to this and I don't have an obvious silver bullet solution.
I think one of the big downsides of using fixtures is that as you've suggested they get out of date. Perhaps you could run a seperate deploy of the app which is deployed in lockstep with your prod deploy? You could have it as an environment that inherits from production but then scatter throughout it features to enable demoing (through
Rails.envchecks). Then sales and marketing can be responsible for putting good data in it and keeping it up to date for demoing.Our setup script through C/I resets the database from fixtures on each deploy. So the data doesn't get "stale" in that way —
But probably by "stale" you meant that you have to constantly update your fixtures when you update the app. And yea, by that definition they are stale stale stale. It feels "un-rails-y" to have to do that.
Se are working on a new approach which is to delete our staging environment, and just use production.
One less thing to maintain I guess. Do you guys have any kind of "Demo" or "Sales" account? How do you manage that?
Tons. Most of the devs have their own demo accounts.
Ahhh that makes sense, they just maintain their own.
Yeah, though they do have a bad habit of hijacking mine