# Development data in migrations

**URL:** <https://www.ruby-forum.com/t/development-data-in-migrations/104984>\
**Category:** Rails\
**Created:** [May 24, 2007, 4:50pm UTC](https://www.ruby-forum.com/t/development-data-in-migrations/104984 "2007-05-24T16:50:19Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![rlwinter](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/ecccb3/32.png) [@rlwinter](https://www.ruby-forum.com/u/rlwinter)\
**Post date:** [May 24, 2007, 4:50pm UTC](https://www.ruby-forum.com/t/development-data-in-migrations/104984/1 "2007-05-24T16:50:19Z")

</div>

Hi all,

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  
migrations.

---

<div class="post-metadata">

**Author:** ![rlwinter](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/ecccb3/32.png) [@rlwinter](https://www.ruby-forum.com/u/rlwinter)\
**Post date:** [September 25, 2007, 11:02pm UTC](https://www.ruby-forum.com/t/development-data-in-migrations/104984/2 "2007-09-25T23:02:44Z")

</div>

There is no built-in environment-aware support in migrations. What we  
end up doing at RHG is having environment specific SQL files and using  
environment-aware data loader to load them. See the details here -

> **[Data Loaders in Migrations](http://revolutiononrails.blogspot.com/2007/02/data-loaders-in-migrations.html)**
>
> Two cases of data usage at RHG (as outlined in the DB Migrations With a Twist post) - migration consolidations and test data creation via ...

Val