Rails Milestone

I hit a little milestone with the Ruby on Rails application I’m working on today — our team put the first development release up on a live server and sent out the URL. Until now we had it running on our local development machines, now it’s deployed on a Linux box running Apache 2 (using CGI, not FastCGI) connecting to a real database. One thing’s for sure, an application feels a lot more real when it’s running on a server, even if it’s just in test mode and nobody is supposed to enter real data in it.

And just so this post isn’t all about praising myself, I’ll provide some technical information that you can probably find elsewhere. One cool feature of Ruby on Rails is that an awareness of the application environment is built in. The application connects to different databases and behaves differently if you tell it that it’s running in development, production, or testing. The development environment is the default and it knows to use the testing environment when you’re running automated tests. The question is how to tell it that it’s supposed to run in production mode.

Rails knows to look at the RAILS_ENV environment variable, so you can set that. You can also set the environment by editing the environment.rb configuration file directly. Editing environment.rb is the wrong way to do it. One of my goals is to be able to export our files directly from Subversion to the deployment directory and have everything running without having to edit any files. If you specify the environment in environment.rb, it makes it hard to do that.

The better choice is to use RAILS_ENV and the best place to set it is in the .htaccess file, where the Rails configuration directives for Apache live anyway. You can use the SetEnv directive to set the variable, and everything works like a charm. (I have .htaccess in version control too, but under a different name so that it, like database.yml, doesn’t get overwritten when I deploy the application.)