命名配置文件 - 热门与否？

Question

我选择了配置文件过程的解决方案，需要证明它的合理性。我很欣赏见解和批评。谢谢！

问题： 我们的Web应用程序有一个包含变量和条件的application.cfm文件

<cfif url = "*dev*" or "jargon123">
    this is a dev enviroment, do devy things
</cfif>

因此，应用程序的开发人员将部署本地实例。把它点起来然后开始四处寻找。问题是配置文件包含生产值。它开始点击生产数据并发送生产电子邮件。此外，由于他们正在点击的网址是http://App_name:PORT或http://localhost，因此永远不会设置开销条件。所以在开发中会发生更多的制作工作。

其他同事想要的是什么：

• Switch语句。 app.cfm将引导环境变量设置为“development”，然后声明一般变量。然后它将进入switch语句并声明特定于环境的变量。我不同意这种方法，因为我们的一些配置文件是100 - 250行。这可能是一个巨大的Switch语句，我不想​​瞎逛。

我选择的解决方案：

• App.cfm已从版本控制中删除并删除。我们现在有多个Applicaiton.Enviroment.cfm文件，即Applicaiton.Prod.cfm，Application.Dev.cfm，Applicaiton.MyName.cfm等。此文件包含所有环境特定数据。我将生产特定设置从条件转移到App.Prod.cfm。现在部署到新环境1.将App.Dev.cfm复制为App.Me.cfm并提交。 2.将所有变量更新为我的个人数据（电子邮件，登录等）3。将App.me.cfm复制为App.cfm并用于配置文件。

我不会讨论为什么我不做其他解决方案，但这是我解决问题的原因：

• 强制部署工程师为环境选择正确的配置文件。没有app.cfm
，该应用程序将无法运行
• 限制用户错误的可能性。方案是用户将数据复制到新环境模式并意外复制生产内容。
• 它更干净，更容易使用 - 配置值完全相互划分。

我发现很多关于使用特定于环境的配置文件的文章，但不是为什么它们更好。这就是这篇文章背后的动机。

Answer 1

我还会删除生产配置并仅提供配置文件的开发版本。原因：

• 配置文件可以包含安全相关数据
• 许多开发人员只是懒散，如果应用程序运行，则不关心配置
• 如果开发人员不使用当前提供的机制（dev url），你可以确定谁设置环境变量？
• 在测试期间使用实时配置可能导致以后生产中的活动调试选项（忘记从配置中删除）

Answer 2

您（开发）需要能够随时在不同版本的软件之间切换。如果每个设置都有自己的配置文件，那么这比它们共享同一个文件要容易得多。

如果您将所有配置都放在一个文件中，则必须阅读整个大文件，确定要忽略的部分。这比阅读整个文件更麻烦。

（我假设您可以在同一台计算机上的不同位置同时安装多个版本的软件。如果不能，则会遇到更大的问题。但即便如此，使用单独的配置文件也是有益的。）< / p>

对于单独的配置文件来说，它们是强大的“优点” - 它们超过了次要的“con”：您必须通过某种机制或其他机制来识别配置文件的位置。它可能是通过环境变量或通过命令行选项，如果两者都未指定，则具有合适的默认值。命令行应该覆盖环境。