Guide: Environments in Rails 1.1

Posted by kev Mon, 22 May 2006 08:29:00 GMT

It’s been a while since I’ve written about environments in Rails, so when one of you wrote in asking for a guide to environments I decided it was time to practice what I preach and update my own documentation. So, here we go. Environments in Ruby on Rails 1.1 coming right up.

As an aside before we get started, I am doing weekly guides now, so if you have a question or an idea for a guide, please send me an email at kevin dot clark at gmail dot com with [idea] in the subject.

Lets get started.

Update: I’ve gotten a good response so far (and is’s only 9:30 in the morning), so if you like it, digg it.

Wait, what’s an environment in Rails?

Remember that very first configuration file you needed to touch up when starting your last Rails project, config/database.yml? It probably looked something like this:

database.yml
development:
  adapter: sqlite
  database: db/dev.sqlite

test:
  adapter: sqlite
  database: db/test.sqlite

production:
  development

When you modified the fields in your database configuration you were really telling Rails what database to use in each of the default environments. They’re aptly named development for developing your application, test for running tests and production for when you’re ready to ship.

Managing your application in environment.rb

Configuration for all environments can be found in config/environment.rb. In this file, application wide preferences are configured like whether to use the Ruby schema format that comes with Rails or SQL to dump and import to each database, what environment to run by default, and whether to use UTC or local time for datetime stamps in the database.

Your config/environment.rb will generally look something like this:

environment.rb
# Uncomment below to force Rails into production mode when 
# you don't control web/app server and can't set it the proper way
# ENV['RAILS_ENV'] ||= 'production'

# Specifies gem version of Rails to use when vendor/rails is not present
RAILS_GEM_VERSION = '1.1.2'

# Bootstrap the Rails environment, frameworks, and default configuration
require File.join(File.dirname(__FILE__), 'boot')

Rails::Initializer.run do |config|
 # ...
end

With the exceptions of the RAILS_GEM_VERSION constant and the setting for what environment to use, the bulk of the configuration in Rails happens within the Rails::Initializer.run block. An instance of Rails::Configuration is passed to the block and is accessible through the config block variable. By setting values in config, options are set throughout Rails.

Unfortunately, RailTies, the Rails library which defines generator behavior, intializer behavior, and the rails script itself isn’t included in the distributed API, but I have documented valid options to Rails::Configuration in a cheat sheet.

Ok, so how are environments configured?

Configuration files for each of the default environments are in config/environments/ which supersede the options set in config/environment.rb and also use an instance of the Rails::Configuration class called config. Lets take a look at the development environment as an example of its use.

Example: the development environment

The development environment is intended to make it easy to make changes to a Rails application and see a result. It also turns on a few features to make debugging easier. The configuration file at config/environments/development.rb is well documented so lets take a look:

development.rb
# In the development environment your application's code is reloaded on
# every request.  This slows down response time but is perfect for development
# since you don't have to restart the webserver when you make code changes.
config.cache_classes     = false

# Log error messages when you accidentally call methods on nil.
config.whiny_nils        = true

# Enable the breakpoint server that script/breakpointer connects to
config.breakpoint_server = true

# Show full error reports and disable caching
config.action_controller.consider_all_requests_local = true
config.action_controller.perform_caching             = false

# Don't care if the mailer can't send
config.action_mailer.raise_delivery_errors = false
What’s going on here?

In this file, each configuration option is set with an accessor of Rails::Configuration.

  • View and Model caching are turned off (with cache_classes and preform_caching set to false) so changes are seen immediately
  • Mail errors aren't shown but the "whiny nil" error is (with raise_delivery_errors and whiny_nils respectively)
  • Breakpointing is enabled
  • Errors are shown no matter who loads the page (with consider_all_requests_local)

How can I make my own environment and why would I want to?

Being able to configure a custom environment can be useful any time you want to have a set of separate configuration or database. For example, I might want to have testing environments for both sqlite which I develop with and mysql which I might deploy an application on.

To create any custom environment:

  • Add an entry in config/database.yml with the label “my_environment”.
  • Add a file config/environments/my_environment.rb and configure accordingly. If the new environment is similar to one of the others, it may make sense to copy the example over and then modify.

You would then select what environment to use with an environment variable, config/environment.rb, or in a web server, just like with the default environments. In my example of a second testing environment, I would also write a rake task to run in my special environment, but that is the subject of another guide.

In 90% of cases, you won’t need to define your own environment, but just in case, now you know!

Posted in ,  | 3 comments

Comments

  1. Avatar DeLynn Berry said about 8 hours later:

    Great article Kevin! I especially like the cheat sheet. It will certainly come in handy, since I always have a problems remembering all the options and invariably end up reading through the source.

  2. Avatar paul said 1 day later:

    this is really well timed for me. i was asking these questions on sunday.

  3. Avatar Dion Almaer said 3 days later:

    Thanks for the info. We do just this to have a “staging” environment for pre-production.

    Cheers,

    Dion

    http://ajaxian.com

Comments are disabled