It is my understanding that the following is “The Rails Way” for setting up a staging environment.
$ cp config/environments/production.rb config/environments/staging.rb
$ atom config/environments/staging.rb # make whatever changes you need
Any sensitive data or data you may want to change without having to push a new version of the app should be placed in environment variables.
However, Heroku is recommending the following:
Your “staging” app or any other custom environments should be run with
RAILS_ENV=production to minimize differences in behavior.
Now I know thoughtbot Learn does it “The Rails Way”. Can I get your thoughts on Heroku’s recommendation and whether or not I should be following it? Advantages v Disadvantages will be useful.
Hey @dwaynecrooks, I recently read the same Heroku post. It seems much better to do it ‘The Rails Way’ and set
RAILS_ENV=staging, however I wouldn’t have wildly different settings in the staging config file for things like assets handling and caching classes.
I keep the behavior the same as production but handle the environment variables separately.
I run a production app on Heroku along with a staging area. I use different S3 buckets for file uploads on staging so I need to set different environment variables for them. I use Figaro and that sets all the Heroku vars by detecting the environment.
I think the main intention behind the Heroku recommendation is to keep the behavior of the app consistent between staging and production.
Thanks for your thoughts.
Should I also be setting
RACK_ENV=staging? I know Rails gives precedence to
RAILS_ENV. But I’m asking in terms of a precaution.
I started off using
dotenv seems a better fit in my projects since I also use
Foreman which can be configured with a
.env file in development. This allows me to keep all my development environment variables in one file.
I’m not sure how
RACK_ENV is referenced on Heroku Cedar. Hopefully someone more knowledgable can jump in and answer that. I’ve never had any issues with just setting
I should look into
dotenv, but I do like the convenience of having all my variables for all environments in one
application.yml file with
Do you use
dotenv for setting production vars too?
With dotenv-deployment you can set your production environment variables with a
dotenv you need to also set
RACK_ENV since it takes precedence when determining the file to use. See the source.
We use suspenders to generate our new projects, which sets up a staging config file like so:
So the staging configurations actually uses the production configuration and then applies specific overrides where necessary. This keeps us from having to make updates in multiple files when we want to change something in both places.
@derekprior That’s really cool. I didn’t know it could be done so elegantly.