有什么理由不在 Heroku 上使用 RAILS_ENV=staging 吗?

Kev*_*nce 4 ruby-on-rails heroku staging

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

\n
\n

创建另一个自定义环境(例如 \xe2\x80\x9cstaging\xe2\x80\x9d)并创建 config/environments/staging.rb 并使用 RAILS_ENV=staging 部署到 Heroku 应用程序可能很诱人。

\n

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

\n
\n

我认为这是一个糟糕的建议,并且与完善的 Rails 最佳实践相冲突。不过,我并不是来争论最佳实践的。我来这里是想问:

\n

有什么理由不在 Heroku 上使用 RAILS_ENV=staging 吗?

\n

如果我创建 staging.rb 文件并像这样设置 xxx_ENV 配置变量,是否会有任何问题?

\n
heroku config:add RACK_ENV=staging --remote staging\nheroku config:add RAILS_ENV=staging --remote staging\n
Run Code Online (Sandbox Code Playgroud)\n

Dam*_*IEU 5

不,如果您这样做,就不会损坏任何东西。

然而,我确实认为 Heroku 就在这里(请注意,我在 Heroku 工作)。它引入了临时环境和生产环境之间可能存在的差异,而它们之间唯一改变的应该是配置变量。
Heroku 已经提供了一种使用命令设置配置变量的安全方法config:set
使用 2 个配置文件意味着您必须两次维护相同的配置,并且可能会出现问题,因为您在暂存中正确更新了配置,但在生产中错误地更新了配置。

附带说明一下,RACK_ENV应该只有 3 个值:productiondevelopmentnone。请参阅https://www.hezmatt.org/~mpalmer/blog/2013/10/13/rack_env-its-not-for-you.html