|
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"
end
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
CMD
end
desc "Run pre-symlink tasks"
task :before_symlink, :roles => :web do
copy_shared
run_tests
end
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.
Comments
Peter Marklund said over 6 years ago:
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 over 6 years ago:
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.