Peter Marklund

Peter Marklund's Home


Rails Deployment: Running Tests in Production with Capistrano

Murphy teaches us that if something can go wrong it will. Given all the differences there are between my development and production server - operating system, web server, database, gems etc. - I can't really feel comfortable deploying my application unless I have first run my test suite not only in development but also in production. Thanks to the beautiful and powerful API of Capistrano this is a walk in the park to accomplish:

desc "Run the full tests on the deployed app." 
task :run_tests do
 run "cd #{release_path} && RAILS_ENV=production rake && cat /dev/null > log/test.log" 

desc "Copy in server specific configuration files"
task :copy_shared do
  run <<-CMD
    cp #{shared_path}/system/voxway.rb #{release_path}/config &&
    cp #{shared_path}/system/database.yml #{release_path}/config

desc "Run pre-symlink tasks" 
task :before_symlink, :roles => :web do

In my current project I am deploying to two identical Linux servers and since Capistrano runs the tests in parallel on those servers I need to keep two distinct test databases in production - one for each server. Credit for this approach goes to Evan Henshaw-Plath who described it nicely.

2 comment(s)


Peter Marklund said 2007-03-27 03:00:

When you run tests you are always in the test environment since RAILS_ENV is hardcoded in test_helper.rb. Setting RAILS_ENV=production means the schema will be cloned from the production database rather than the development database. I could of course set up a development database on the production servers, but that doesn't seem to make sense.

Jarkko Laine said 2007-03-27 02:50:

I think you should never, ever, run tests against a production database. Remember that the database is swept away and built again when the fixtures are loaded. I don't think you're doing it, either, but "RAILS_ENV=production" implies you are.