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:
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
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.
config/environment.rb will generally look something like this:
# 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:
# 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
- 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
- Breakpointing is enabled
- Errors are shown no matter who loads the page (with
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.ymlwith the label “my_environment”.
- Add a file
config/environments/my_environment.rband 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!