我一次又一次面临着多个环境的问题，这些环境必须针对将在所有这些环境中运行的应用程序单独配置（例如QA，区域生产环境，开发，升级等），我想知道什么是组织不同配置的最佳方式？
它会在数据库中吗？每个环境有不同的配置文件或者可能是具有不同section / xml标签的相同文件？如何部署这些？嵌入在应用程序中？或者在安装后手动插入以便就地修改？
这个问题不是特定于技术的 - 我使用过.net和Java，网络应用程序和桌面应用程序，这个问题一次又一次出现。我希望学习不同的方法来调整混合动力来解决这个问题。
编辑：我必须指出一点需要注意 - 当配置是部署解决方案的一部分时，它通常安装在主机上的root用户下。在大型组织中，开发人员通常没有对生产主机的root访问权限，因此对配置的任何更改都需要新的构建和部署。毋庸置疑，这不是最好的方法 - 尤其是那些拥有非常严格的发布流程且涉及多个团队和审批级别的组织......（叹息我知道！）
答案 0 :(得分：1)
这个问题很难回答，因为它有些模糊。据我所知，没有与技术无关的配置方法。具体如何设置配置将取决于所讨论的语言/技术。
我对.net并不熟悉，但对于java，一种流行的方法是拥有maven build set up with different profiles。每个配置文件都特定于环境。然后，您可以定义具有特定于环境的值的不同属性文件，上面链接中的示例为：
- environment.properties - 这是默认配置，默认情况下将打包在工件中。
- environment.test.properties - 这是测试环境的变体。
- environment.prod.properties - 这与测试版本基本相同，将在生产环境中使用。
然后您可以按如下方式构建项目：
mvn -Pprod package
答案 1 :(得分：1)
借用Jez Humble和David Farley的书“Continuous Delivery (page 41)”，你可以：
- 您的构建脚本可以在构建时提取配置并将其合并到您的二进制文件中。
- 您的包装软件可以在打包时注入配置，例如在创建装配，耳朵或宝石时。
- 您的部署脚本或安装程序可以获取必要的信息或询问用户，并将其传递给您的应用程序 部署时间是安装过程的一部分。
- 您的应用程序本身可以在启动时或运行时获取配置。
他们认为在构建和编译时注入配置文件是不好的做法，因为您应该能够将相同的二进制文件部署到每个环境。
我的经验是，您可以将每个环境（敏感信息除外）的所有配置文件烘焙到部署文件（war，jar，zip等）。并且您设计应用程序以在启动时接收额外参数，从应用程序启动时间内获取正确的配置文件集（来自提取的部署文件，或者来自本地/远程文件系统，如果它们是敏感的，或来自数据库）
答案 2 :(得分：0)
我有好消息和坏消息。
好消息是Config4 *（其中我是维护者）通过支持自适应配置巧妙地解决了这个问题。基本上，这是配置文件使其自身适应运行它的环境（包括主机名，用户名，环境变量和命令行选项）的能力。有关详细信息，请阅读“使用入门”手册的Chapter 2。别担心：这是一个简短的章节。
坏消息是，目前，Config4 *实现仅适用于C ++和Java，因此您的.Net应用程序运气不佳。即使使用C ++和Java应用程序，将Config4 *改造为现有应用程序也不会有实际意义。因此，我建议仅在 new 应用程序中使用Config4 *。
尽管有坏消息，但我认为阅读Config4 *文档的上述章节是值得的，因为这样做可能会为您提供适合您需求的想法。