Rails:区分舞台和生产

发布于 2024-09-14 04:27:49 字数 323 浏览 0 评论 0原文

我有一个生产服务器和一个临时服务器,新功能在投入生产之前会在其中进行测试。登台服务器在物理上与生产服务器不同(不同的主机具有不同的 url),但它尽可能地模仿它(即相同的包、相同的 gem 等)。

两台服务器上的 Rails.env = '生产'

我的问题是,在某些情况下,我需要在登台时的行为与在生产中的行为不同。

例如,一项新功能可能会向生产中的用户发送大量电子邮件;但当我测试它时,我宁愿将它们发送到“测试”电子邮件帐户。

检测我所在的服务器的最佳方法是什么?

我想尽可能“铁路”地做到这一点。

多谢。

I've got a production server and a staging sever in which new features are tested before moving them to production. The staging server is physically different from the production one (different hosts with different urls), but it mimics it as much as possible (i.e. same packages, same gems, etc).

Rails.env = 'production' on both servers.

My problem is that in some cases I need different behaviour on staging than in production.

For example, a new feature might send massive emails to users on production; but while I'm testing it I'd rather have them sent to a 'test' email account.

What is the best way to detect the server I'm at?

I'd like to do it as "raily" as possible.

Thanks a lot.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

匿名的好友 2024-09-21 04:27:49

一般来说,这就是您使用不同环境的原因。实际上,临时环境通常非常接近生产环境,但关闭了真实电子邮件等功能。

您不限于开发/测试/生产 - 您可以在您想要的任何名称的环境下运行。只需创建一个 config/environments/staging.rb 文件,在其中设置所需的值,然后使用 RAILS_ENV=staging 启动您的应用程序 - 这就是全部。这样您就可以模拟您的生产环境,但如果您不希望在实际上线之前激活这些功能,则可以根据需要打开或关闭功能。

Generally, this is why you'd use different environments. Practically speaking, a staging environment is usually very close to production, but with things like real emails turned off.

You aren't limited to development/test/production - you can run under an environment named anything you want. Just create a config/environments/staging.rb file, set the values you want in there, and start your app with RAILS_ENV=staging - that's all there is to it. That way you can emulate your production environment, but twiddle features on or off as desired when you don't want them active before you actually go live.

清泪尽 2024-09-21 04:27:49

恐怕这个答案不是很有帮助。

Railsy 方式是让不同环境的环境仅在配置(资产主机、数据库等)上有所不同。因此,使用具有虚拟或测试电子邮件地址的用户的不同数据库将是最简单的方法。

如果您通常从生产环境进行克隆,我建议通过 script/dbconsolescript/console 或只是简单的 rake 更新所有用户的电子邮件代码>任务。

如果您想限制/控制功能,那么我建议通过源代码控制来实现,即部署不同的修订版。

I am afraid this answer isn't terribly helpful.

The railsy way is to have environments differ only in configuration (asset host, database etc.) for different environments. So a different database with users having dummy or test email addresses would be easiest way to go about it.

If you are generally cloning from Production, I recommend updating emails of all users, either through script/dbconsole or script/console or just a plain simple rake task.

And if you want to limit / control the features, then I'd recommend doing that through source control, i.e. by have different revisions deployed.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文