Quick and Dirty Rails Environments
A quick tip — When I’m deploying Rails apps to Staging or Beta I try to keep the configuration as close to Production as possible. I’ve gotten bitten one too many times by things that only break in production due to configuration (assets for example).
The simple way to avoid this issue is to use the exact same configuration for those extra environment, but there’s a wrong way and a right way.
The wrong is to copy the config/environments/production.rb
in to
config/environments/staging.rb
(or beta.rb
). It’s too easy to make
changes to production.rb
and then forget to propagate them to the
other stages.
The right way is including the production config in your other environments:
1
|
|
It’s simple, there’s no question that Staging and Production have the same config. If you do need to tweak the stages configuration, you can to it after the require:
1 2 3 4 |
|
However, avoid this as much as you can. It quickly defeats the idea of the “Same as config as Production”.
Furthermore, it leads to really ugly conditionals, like:
1
|
|
(Didn’t know about the ‘?’ tests? Way less ugly than Rails.env ==
'production'
) We’ll tackle that problem next time.