在Heroku上使用RAILS_ENV=staging是否存在任何不适当的原因？

Question

Heroku文档https://devcenter.heroku.com/articles/deploying-to-a-custom-rails-environment表示我不应该使用staging.rb文件来定义我的staging环境。

创建另一个自定义环境，例如“staging”，并创建config/environments/staging.rb，并使用RAILS_ENV=staging部署到Heroku应用程序可能很诱人。

这不是一个好的做法。相反，我们建议始终以生产模式运行，并通过设置您的配置变量修改任何行为。

我认为这是可怕的建议，并与既定的Rails最佳实践相冲突。但是，我不是在这里争论最佳实践。我在这里问：

在Heroku上使用RAILS_ENV=staging有没有任何原因不使用？

如果我创建一个staging.rb文件并像这样设置xxx_ENV配置变量，是否会出现任何问题？

heroku config:add RACK_ENV=staging --remote staging
heroku config:add RAILS_ENV=staging --remote staging

- Kevin Lawrence

Answer 1

不会有任何问题，如果您这样做。

但是，我认为Heroku是正确的（请注意，我在Heroku工作）。 这会在您的Staging和Production环境之间引入可能的差异，而唯一变化的应该是配置变量。
Heroku已经提供了安全的设置配置变量的方法，使用config:set命令即可。
使用2个配置文件意味着您必须维护相同的配置两次，并且可能会出现问题，因为您在Staging中已正确更新了配置，但在Production中却错误更新了。

顺便说一下，RACK_ENV只应该有3个值：production、development和none。请参阅https://www.hezmatt.org/~mpalmer/blog/2013/10/13/rack_env-its-not-for-you.html

- Damien MATHIEU

---

谢谢提醒关于RACK_ENV的事情。我以前从未设置过RACK_ENV，但在Stack Overflow上看到了其他关于Heroku的问题的答案中有提到它。我没有想到去质疑它，现在会将其设置回“production”。 - Kevin Lawrence

当我有多个类似于生产环境的环境时，我会将通用代码因素提取到名为“production_common.rb”的文件中。剩下的是自定义域内容（而不是仅仅Rails配置），例如主机名、要通知的电子邮件地址、要使用的Google Analytics ID、allow_robots等。我发现将所有这些内容放在一个地方更容易通过源代码管理，并轻松地比较一个环境与另一个环境之间的差异。 - Kevin Lawrence

Answer 2

当您部署时，Heroku会发出一些警告，但是我可以确认我曾在Heroku上运行过具有RAILS_ENV=staging的演示应用程序。只要设置正确的环境变量和Gemfile组，它就可以正常工作。 我的猜测是，他们建议不要使用自定义环境的原因是他们有一些操作工具，假设您的Rails应用程序在production环境下运行，但到目前为止，我没有遇到问题。

- eugen