在不使用RAILS_ENV的情况下为Ruby应用程序指定环境的标准方法是什么?

时间:2023-01-29 23:31:11

When developing a Ruby application, how can I distinguish in code between development, test and production environments without using RAILS_ENV? I've seen some apps that don't even use Rails using that variable, which doesn't make much sense to me.

在开发Ruby应用程序时,如何在不使用RAILS_ENV的情况下在开发,测试和生产环境之间区分代码?我见过一些使用该变量甚至不使用Rails的应用程序,这对我来说没有多大意义。

Of course I can just use a different name, but is there a standard one? Also, would it be bad to set this on code, in some sort of configuration object, instead of using the system's environment variables?

当然我可以使用不同的名称,但是有标准吗?另外,在某种配置对象中设置此代码而不是使用系统的环境变量会不好?

PS: sorry if this is too basic, but it's hard to search for an answer since the results are always Rails related.

PS:对不起,如果这太基础了,但很难找到答案,因为结果总是和Rails有关。

3 个解决方案

#1


0  

You are free to invent your own semantics, and your own ways of determining which configuration is in use. The environment names of test, development, production have become well-known standards, sometimes with the addition of release-management steps such as smoke, uat, staging etc. However, there is no requirement to use environments as a concept in the first place, nor is there a generic approach that could be applied across all Ruby projects - the set of possible applications is too broad.

您可以*地创建自己的语义,以及自己确定正在使用哪种配置的方法。测试,开发,生产的环境名称已成为众所周知的标准,有时还增加了烟雾,尿素,分期等发布管理步骤。但是,首先不需要将环境作为概念使用,也没有可以在所有Ruby项目中应用的通用方法 - 可能的应用程序集太宽泛了。

If you are creating a web application that conforms to the rack API (for hosting in Apache/Passenger or Thin or other server that supports Rack), it is common to use RACK_ENV environment variable to control the choice of named environment (and which part of config to then use) - Sinatra config will use this for example, and Rails will fall back to it.

如果要创建符合机架API的Web应用程序(用于在Apache / Passenger或Thin或其他支持Rack的服务器中托管),通常使用RACK_ENV环境变量来控制命名环境的选择(以及配置然后使用) - 例如,Sinatra配置将使用它,并且Rails将回退到它。

#2


3  

The Standard

标准

Rails.env.development?
Rails.env.test?
Rails.env.production?

Don't use RAILS_ENV

不要使用RAILS_ENV

RAILS_ENV is being deprecated and will cause warnings and/or errors.

RAILS_ENV已被弃用,将导致警告和/或错误。

References

参考

#3


0  

Rails.env = 'production'
Rails.env.production? # true

#1


0  

You are free to invent your own semantics, and your own ways of determining which configuration is in use. The environment names of test, development, production have become well-known standards, sometimes with the addition of release-management steps such as smoke, uat, staging etc. However, there is no requirement to use environments as a concept in the first place, nor is there a generic approach that could be applied across all Ruby projects - the set of possible applications is too broad.

您可以*地创建自己的语义,以及自己确定正在使用哪种配置的方法。测试,开发,生产的环境名称已成为众所周知的标准,有时还增加了烟雾,尿素,分期等发布管理步骤。但是,首先不需要将环境作为概念使用,也没有可以在所有Ruby项目中应用的通用方法 - 可能的应用程序集太宽泛了。

If you are creating a web application that conforms to the rack API (for hosting in Apache/Passenger or Thin or other server that supports Rack), it is common to use RACK_ENV environment variable to control the choice of named environment (and which part of config to then use) - Sinatra config will use this for example, and Rails will fall back to it.

如果要创建符合机架API的Web应用程序(用于在Apache / Passenger或Thin或其他支持Rack的服务器中托管),通常使用RACK_ENV环境变量来控制命名环境的选择(以及配置然后使用) - 例如,Sinatra配置将使用它,并且Rails将回退到它。

#2


3  

The Standard

标准

Rails.env.development?
Rails.env.test?
Rails.env.production?

Don't use RAILS_ENV

不要使用RAILS_ENV

RAILS_ENV is being deprecated and will cause warnings and/or errors.

RAILS_ENV已被弃用,将导致警告和/或错误。

References

参考

#3


0  

Rails.env = 'production'
Rails.env.production? # true