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.env checks). 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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.