的背景：
步骤1 – >我们有一个盒子,通过在具有特定配置的测试模式下运行它来运行应用程序的单元和功能测试.
步骤2 – >在步骤1成功后,我们通过在另一个框中以不同配置集的测试模式运行应用程序来运行应用程序的集成测试.
步骤3 – >在步骤2成功后,我们通过在性能测试框中以生产模式运行应用程序来运行应用程序的性能测试.
步骤4 – >在步骤3成功后,构建被认为是稳定的,并且UAT框用该代码库更新,并且应用程序在生产模式下运行,以供客户查看和反馈.
步骤5 – >使用来自客户的GO,生产框将使用代码库进行更新.
步骤1 – >我们有一个盒子,通过在具有特定配置的测试模式下运行它来运行应用程序的单元和功能测试.
步骤2 – >在步骤1成功后,我们通过在另一个框中以不同配置集的测试模式运行应用程序来运行应用程序的集成测试.
步骤3 – >在步骤2成功后,我们通过在性能测试框中以生产模式运行应用程序来运行应用程序的性能测试.
步骤4 – >在步骤3成功后,构建被认为是稳定的,并且UAT框用该代码库更新,并且应用程序在生产模式下运行,以供客户查看和反馈.
步骤5 – >使用来自客户的GO,生产框将使用代码库进行更新.
现在,从上述步骤我们观察到,在步骤1和2中,当应用程序在测试模式下运行时,它具有不同的配置.步骤3,4和5的情况类似.
在这种情况下,推荐的做法是什么？我们有YAML配置文件,但我个人认为维护大量配置文件没有意义.所以,我改变了做法
“每个环境配置文件”
至
“每个rails模式配置文件,将变量外部化到linux环境”.
我是在正确的轨道上吗？我不采取行动,简化事情吗？
这两种方法的优点和缺点是什么？
解决方法
根据我的经验,环境变量是最后的配置选项.它们绝对有它们的位置,但应用程序通常应首先检查一些其他更可靠和明确有意的配置选项.我强烈建议从YAML文件加载配置,并仅使用环境变量作为后备.始终假设您的环境变量将适用于系统范围内的所有内容,并假设它会在某个时刻意外取消设置或设置为错误的值.即,您的应用程序不应提交seppuku,因为某些配置目录设置为/并且它没有权限(或者更糟糕的是您擦除驱动器,因为应用程序以root身份运行).或者更有可能的是,像你的RAILS_ENV这样的东西被设置为测试什么时候它应该是生产而没有人实现,现在用户正在将数据写入错误的地方或者/ dev / null由于所有500个.
就个人而言,我喜欢在我回退到配置值的环境变量时随时删除logger.warn消息.
老实说,对于您的确切问题,我可能会传递配置值,以便在命令行启动哪个环境.