Keep Your Demo Data Separate From Your Seed Data

File this under the “duh…” category… I don’t know why this wasn’t obvious.

Joey and I have been working on our rather large app for a while now, with a bunch of demo accounts and data added with our seed files. When we finally started deploying versions of the app to our staging environment so that our client could watch as we made progress, we realized the need to keep our demo accounts and data separate from our seed data. The seed data was changing rapidly and we needed to re-seed the database on every deploy, but we didn’t want to lose the demo accounts or the accounts that we had created for the clients.

The answer to this is pretty simple / obvious, once Brian Hogan showed me the way he handles it: create a custom rake task that puts the demo accounts and data into the database, so that we can run it only when we need to. That way, when db:seed is run, we won’t wipe out our accounts.

namespace :bootstrap do

   task :foo => :environment do
     u = User.create :login => "foo", :password => "1234", :password_confirmation => "foo"
     u.roles << Role.find_by_name "admin"
     u.roles << Role.find_by_name "user"
     u.projects.create :name => "My test project"
   end

   task :demo => :environment do
     u = User.create :login => "demo", :password => "1234", :password_confirmation => "foo"
     u.roles << Role.find_by_name "user"
     u.projects.create :name => "My demo project"
   end

   task :all do
      Rake::Task["db:schema:load"].invoke
      Rake::Task["db:seed"].invoke
      Rake::Task["bootstrap:demo"].invoke
      Rake::Task["bootstrap:foo"].invoke
   end
end

Now I can run `rake bootstrap:demo` any time I need to, or not at all when doing general deployments and re-seeding the staging database. As an added bonus, the demo data is created using our actual models. This means they are all validated at runtime, ensuring we had good demo data in place.

A much larger problem, though, is how to handle the maintenance of seed data over time in a rather large application. This is a much more difficult problem with a lot more context and consideration. I think we finally have a solution, though… and it’s much easier than expected. But, that’s another blog post hopefully coming soon; after we’ve had a chance to run this through it’s paces and verify it really does what we want.