Developer-Specific Environments in Rails

When you’re working on Ruby on Rails applications in a multiple developer team, you’ll often need to localize certain application settings. You might have your own database credentials, mail server settings, and so on. As a convention, development.rb can be used for settings specific to your development environment. But once this file is added to the source code repository, every developer on the team shares the settings. Let’s look at a couple options for handling development environment settings.

Create a New Environment

Rails allows you to define new environments without much effort. Simply save a new configuration file to config/environments (example: development-phil.rb) with your custom settings. Then in database.yml, you’ll need to add a section that matches the name you used (development-phil).

When you start your Mongrel, just pass in your new environment name:

script/server --e=development-phil

Screenshot of command line output when starting a Rails application using a custom-defined environment

The only caveat with this approach is to be aware of any code in your app that evaluates whether the current environment is ‘development.’ Assuming you’re using a naming convention of development-mycustomname.rb for your environment, simply swap out any instance of this code:

if RAILS_ENV == 'development'

with this:

if RAILS_ENV.include? 'development'

Initializers

Rails 2 improved configuration management by allowing you to break apart start-up settings into individual files. These settings are stored in config/initializers and are processed after environment.rb (and development.rb) are loaded.

If you only have a couple settings you want to localize (e.g. SMTP server), you may not want to spend the effort defining a new development environment as described above. Instead, create a new initializer file (example: mysettings.rb) but do not add it to source control. Note: both Subversion and Git allow you to set ‘ignore’ properties on specific files in case you are worried about accidentally checking these in (links below).

An initializer can be used to override existing settings in environment.rb and development.rb. The app may have a set of global settings common to all developers but within the initializer you can redefine them as needed.

If you work on multiple projects and are always re-applying the same local settings to your Rails apps, you can externalize your initializer in a common location and then create a symbolic link inside your Rails app. Just save your mysettings.rb outside of your Rails path and from within the console, navigate to your app’s config/initializers folder and type:

ln -s /apps/mysettings.rb

Additional Resources

How to ignore specific files during source code repository check-ins:
Git: .gitignore
Subversion: propset/propedit


About this entry