Re:Beyond the default Rails environments
by gkop on Thursday June 13, 2013 @12:40PM
(#5874987)
Tried this and it didn't work for me. I found each additional RAILS_ENV value was an annoying point of divergence between environments that should be as like as possible.
Eg, the whole point of staging is to be as like to production as possible, and running the staging server in RAILS_ENV=production is a dead easy way to accomplish this goal. For the very few differences (eg database config), I further refine the production environment by consulting a SECONDARY_ENV variable that may be set to either production or staging.
Eg, ideally CI is as close to the developer's test environment as possible, so that tests that pass locally pass in CI and vice-versa, and running the CI jobs in RAILS_ENV=test is a dead easy way to accomplish this goal. For the very few differences (eg using xvfb in CI), I further refine the test environment by consulting a CI variable that may be set to either true or false.
Eg, the whole point of staging is to be as like to production as possible, and running the staging server in RAILS_ENV=production is a dead easy way to accomplish this goal. For the very few differences (eg database config), I further refine the production environment by consulting a SECONDARY_ENV variable that may be set to either production or staging.
Eg, ideally CI is as close to the developer's test environment as possible, so that tests that pass locally pass in CI and vice-versa, and running the CI jobs in RAILS_ENV=test is a dead easy way to accomplish this goal. For the very few differences (eg using xvfb in CI), I further refine the test environment by consulting a CI variable that may be set to either true or false.