平台特定的配置应该在应用程序包中吗？

Question

在我的工作地点，有些人认为可以在应用程序包中嵌入（作为.properties文件（s））平台特定的配置项（如后端主机名/ IP地址，数据库连接细节等） （一个Web应用程序.war文件）。我认为这是一个坏人坏事，原因如下：

• 有需要为每个目标平台的单独封装（可能是一个开发实验室，模型实验室，生产等）
• 建设高架 - 构建脚本通常会构建一组目标应用程序包（它们都是在假定此版本是最终版本的情况下同时构建的）
• 配置项目的管理工作（例如源代码/版本控制）需要（理论上它意味着甚至保留客户系统的用户名/密码）
• 无法确定包装的版本是否正确（校验我们eless） - 在实验室中测试的包的可执行部分与迁移到生产中相同吗？

这种方法的结果是（用于Java Web应用程序），在客户环境中，管理员部署软件包，关闭应用程序服务器，复制特定于平台的CONFIGS了在包中嵌入那些顶部，并重新启动应用服务器。痛苦。

也许更好的方法是外部化平台特定的配置项 - 不要将它们嵌入.war文件中，并且没有应用程序将它们引用到展开的.war文件目录树中。相反，将配置项目放在应用程序目录之外的“.. \ conf”目录中。这带来的利益：

• 有且仅有一个应用程序包的应用程序的
• 没有“客户”平台特定的CONFIGS的知识（用户ID可执行组件
• 缩短建设高架（相比于以上） /密码）
• 可审核性（能够在应用程序包上执行校验和，在实验室或客户平台上执行相同操作，并且对可执行文件是相同的高度置信度） - “我们测试的是你有“
• 部署是一个更短的过程 - 德挂起应用程序服务器功能，转储相关目录中的应用程序.war文件，如果没有配置更改（通常是这种情况）， 会使应用程序服务器退出。

此方法确实需要应用程序能够引用应用程序目录之外的文件。这方面有一个小小的安全考虑。应用程序服务器环境变量使应用程序能够在其应用程序目录（或CLASSPATH）外定位文件。

我正在寻找社区来投票。然后，我可以回到我的工作同事身边，并说：“不要只听我说，看看Stackoverflow社区估计什么。”

Answer 1

我看到三种模式：

1. 配置的应用程序。每个环境的新版本
2. Configs（复数）在应用程序中。由某些环境控制选择的适当构建
3. 配置与应用程序分开。通过一些环境控制选择配置。

这article描述了一种可能的方式来实现的方法3.

我的意见：方案1，需要新版本的每个环境，这只是不适合有关通过测试的阶段promotaing应用我的想法。

选项1 和 2都存在发布后如何更改配置项目的问题。应用程序的新版本改变诊断级别？当然不是。

选项3稍微复杂一些，这是一个在群集环境中解决问题的细节。但我看到主要的好处。我会非常感兴趣地看到选项1或2被认为更好的情况。