RAILS_ENV Expectations!

[Wilfongjt]

RAILS_ENV, What a mess!

I see @beyondtheteal's logic in #141, RAILS_ENV is set to "production" in the staging environment and this contradiction screams MISTAKE! @Ross-Hunter #141, I see the order we would gain by picking one method for setting environment variables.

We need some rules to sort out what we expect RAILS_ENV to do.

Requesting Proposals

• Please provide your own expectations in a comment and in the form of a rule set.
• Add a bullet for any additional rules
• Bullets should be tight and tidy. Long unorganized rambles will be ignored so I suggest bullet points and logical organization

[Wilfongjt]

This proposal stands until something better is proposed.

I propose:

Production Environment Setting RAILS_ENV='production' should:

• only be defined and set in Heroku's lgrow production environment settings
• turn dotenv OFF
• render the environment vars in .env useless in the production environment
• switch the application to the production database
• turn testing OFF
• RAKE?

Staging Environment Setting RAILS_ENV='staging' should:

• only be defined and set in the Heroku lgrow-staging instance's settings
• turn dotenv OFF
• render the environment vars in .env useless in the staging environment
• switch the application to the staging database
• turn testing ON
• RAKE?

Development Environment Setting RAILS_ENV='development' should:

• only be set in your development .env file
• turn dotenv ON
• switch to a development database
• turn testing ON
• RAKE?

What about RAKE what does RAKE do or not do in staging and production?

[Ross-Hunter]

My proposal is to follow 12 Factor configuration and rely on environment variables directly. With Heroku, you are essentially forced to do this anyway.

TL;DR: I don't believe there is a currently a problem and the existing of the config/staging.rb file is causing confusion.

[Wilfongjt]

I understand deployment as a process that can be separated into development, testing, and production. When I saw that Heroku was separated into Review, Staging and Production, I thought development, testing, and production. But I'm not so sure that Review and Staging are what I think they are.

Can you fill-in the definitions for me?

[Ross-Hunter]

From the RAILS_ENV side, best practice is that the test environment is the local unit testing environment, development is the local development environment and any deployed environment is production.

Any differences between deployed environments should be controlled by environment variables. It's best to keep the differences between environments minimal so that deploying to production is not a gamble on whether or not it will work correctly.

Heroku is fantastic at promoting this configuration and it's a huge advantage of the platform.