I’ve seen examples on including “development data” in migrations. I
do this myself, and it seems to be a great convenience for “trying
out” an application. This saves all the trouble of entering the setup
data that may be necessary to use the application.
My question is about what to do when it comes time to run the
migrations on the production database. How do we keep all this
“development data” from infecting the production database. Is there
some way to skip migrations (or have the migration do nothing) when
run with RAILS_ENV set to “production?”
There may also be cases where I may want some of the data to be loaded
in the production database, which could include things like
enumerations providing some defaults that can be expanded upon later
by the users or administrators.
I assume this could be accomplished by using conditionals embedded
within the migrations, given that they are basically just Ruby code.
However, I’m also guessing that there may be some “built-in” support
for this that I’ve not yet found in my research on Rails and