6.5. Runtime Environments

By default, Rails applications have three environments: development, test, and production. As you saw earlier, development is the default environment. These three modes are configured to act differently and in accordance with their purpose. The easiest way to understand the differences among them is to look at their configuration files located in configenvironments.

6.5.1. Development

This is the code from configenvironmentsdevelopment.rb:

# Settings specified here will take precedence over those in config/environment.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

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

# Don't care if the mailer can't send
config.action_mailer.raise_delivery_errors = false

The comments and code are pretty much self-explanatory.

In development mode the classes are not cached. This is done so that the application's code is reloaded at every request, providing an immediate feedback loop for the developer, who therefore does not need to restart the Web server for code changes (the exception being code within the config folder).

If you accidentally call methods on the nil object, these are logged. The errors and their backtraces are shown in the browser, because every request is considered local. Caching is not enabled, in order to make it easier to troubleshoot problems. And finally, Rails also ignores delivery error messages when using ActionMailer to send emails.

Not surprisingly, it's an environment tailored for development, where the programmer gets immediate feedback for any possible errors that might arise (mail delivery excluded).

6.5.2. Test

The code for configenvironments est.rb is as follows :

# Settings specified here will take precedence over those in config/environment.rb

# The test environment is used exclusively to run your application's
# test suite.  You never need to work with it otherwise.  Remember that
# your test database is "scratch space" for the test suite and is wiped
# and recreated between test runs.  Don't rely on the data there!
config.cache_classes = true

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

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

# Disable request forgery protection in test environment
config.action_controller.allow_forgery_protection    = false

# Tell Action Mailer not to deliver emails to the real world.
# The :test delivery method accumulates sent emails in the
# ActionMailer::Base.deliveries array.
config.action_mailer.delivery_method = :test

This is a special environment because you'd like to test the application as if it was in production mode, but you also need to be able to catch errors, as you do in development mode. It's also peculiar because, like the first comment explains, the test environment is used exclusively to run the application's test suite. As such, you can cache classes, but you still need to log errors for methods that are accidentally invoked on nil, and be able to get full error reports. Furthermore, caching can be disabled, just as forgery protection can be. Emails are not actually delivered but placed in the ActionMailer::Base.deliveries array to facilitate their testing.

6.5.3. Production

In production mode you don't want to reveal details of the errors to the end user, and you'd like to cache anything that can be cached. This is accomplished with the following default code:

# Settings specified here will take precedence over those in config/environment.rb

# The production environment is meant for finished, "live" apps.
# Code is not reloaded between requests
config.cache_classes = true

# Enable threaded mode
# config.threadsafe!

# Use a different logger for distributed setups
# config.logger = SyslogLogger.new

# Full error reports are disabled and caching is turned on
config.action_controller.consider_all_requests_local = false
config.action_controller.perform_caching             = true

# Use a different cache store in production
# config.cache_store = :mem_cache_store

# Enable serving of images, stylesheets, and javascripts from an asset server
# config.action_controller.asset_host                  = "http://assets.example.com"

# Disable delivery errors, bad email addresses will be ignored
# config.action_mailer.raise_delivery_errors = false

Notice that the environment already offers commented-out code for defining a different logger, cache store, the enablement of an asset server, and the ability to decide whether delivering to bad addresses should be ignored.

In Rails 2.2 you can now write (or uncomment):

config.threadsafe!

That single line enables multithreaded dispatching of your application and thread safety. This improves performance and reduces the amount of memory required to run a given load. As such it's a highly recommended option in production mode.

6.5.4. Your Own Environment

Occasionally you may wish to define your own environment mode. You can easily accomplish this by creating a Ruby file in configenvironments. You can then copy over the code of one of the three default environments and customize it as you wish. In configdatabase.yml you will need to provide the connection details for this new environment as well.

This means that you'll be able to define environments for troubleshooting unforeseen issues with a live production application, directly from your machine, or define environments for different configurations as needed.