命名配置文件 - 热与否？答案

【问题标题】：Named Config files - Hot or Not?命名配置文件 - 热与否？
【发布时间】：2011-06-27 18:45:17
【问题描述】：

我已经为我们的配置文件流程选择了一个解决方案，并且需要证明它的合理性。我很感激洞察力和批评。谢谢！

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

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

因此，应用程序的新开发人员将部署本地实例。点燃它并开始四处寻找。问题是配置文件包含生产值。它开始打击生产数据并发送生产电子邮件。此外，由于他们点击的 url 是 http://App_name:PORT 或 http://localhost - 开发条件永远不会设置。因此，开发中发生了更多生产方面的事情。

其他同事想要什么：

Switch 语句。 app.cfm 将引导环境变量设置为“开发”，然后声明通用变量。然后它将进入 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，该应用将无法运行
限制用户错误的可能性。场景是用户将数据复制到新的环境模式并意外复制生产内容。
它更干净，更易于使用 - 配置值彼此完全分开。

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

【问题讨论】：

标签： version-control configuration app-config

【解决方案1】：

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

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

【讨论】：

【解决方案2】：

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

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

（我假设您可以在同一台机器上的不同位置同时安装多个版本的软件。如果不能，那么问题就更大了。但即便如此，拥有单独的配置文件也是有益的。）

对于单独的配置文件，这些是强大的“优点”——它们胜过次要的“缺点”：您必须通过某种机制确定配置文件的位置。它可能是通过环境变量或命令行选项，如果两者都没有指定，则使用合适的默认值。命令行应该覆盖环境。

【讨论】：