Version control 命名配置文件-热还是不热？

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

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

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

这是一个开发环境，做很多事情

因此，应用程序的新开发人员将部署一个本地实例。点燃它，开始四处乱摸。问题是配置文件包含生产值。它开始点击生产数据并发送生产电子邮件。此外，由于他们所访问的url是或，因此从未设置开发条件。因此，在dev中有更多的生产工作正在进行

其他同事想要什么：

• Switch语句。app.cfm将以设置为“development”的环境变量开头，然后声明常规变量。然后它将进入switch语句并声明特定于环境的变量。我不同意这种方法，因为我们的一些配置文件有100-250行。这可能是一个巨大的转变声明，我不想卷入其中

我选择的解决方案：

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

我不会详细说明我为什么不采用其他解决方案，但以下是我提出解决方案的原因：

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

---

我找到了很多关于使用特定于环境的配置文件的文章，但没有找到为什么它们更好。这就是本文背后的动机。

我还将删除生产配置，只提供配置文件的开发版本。原因:

• 配置文件可能包含与安全相关的数据
• 许多开发人员只是懒散，如果应用程序运行，用户就不关心配置
• 如果开发人员不使用当前提供的机制（devurl），您可以确定他们设置了环境变量吗
• 在测试期间使用live config可能会导致以后在产品上出现活动调试选项（忘记从配置中删除）

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

如果在一个文件中有所有配置，则必须读取整个大文件，决定忽略哪些部分。这比仅仅读取整个文件更混乱

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

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