Configuration 生产与QA配置

我一次又一次地面临这样一个问题：对于一个将在所有环境中运行的应用程序，必须单独配置多个环境（例如QA、区域生产环境、开发、暂存等），我想知道组织不同配置的最佳方式是什么

它会在数据库里吗？每个环境有不同的配置文件？或者同一个文件具有不同的节/xml标记？那么，这些将如何部署？嵌入到应用程序中？或在安装后手动放入待修改的位置

这个问题不是特定于技术的——我曾经使用过.net和Java、web应用程序和桌面应用程序，这个问题一再出现。我希望学习不同的方法，也许可以采用混合动力来解决这个问题

---

编辑：我必须指出一个警告-当配置是已部署解决方案的一部分时，它通常安装在主机上的

root

user下。在大型组织中，开发人员通常没有对生产主机的root访问权限，因此对配置的任何更改都需要新的构建和部署。不用说，这不是最好的方法——特别是在那些拥有非常严格的发布流程（涉及多个团队和批准级别）的组织中。。。（唉，我知道！）

这个问题很难回答，因为它有点模糊。据我所知，没有技术不可知的配置方法。具体如何设置配置将取决于所讨论的语言/技术

我对.net不太熟悉，但对于java，一种流行的方法是使用。每个概要文件都特定于一个环境。然后，可以定义具有特定于环境的值的不同属性文件，上面链接中的示例如下：

• 这是默认配置，默认情况下将打包在工件中
• environment.test.properties-这是测试环境的变体
• environment.prod.properties-这与测试变体基本相同，将在生产环境中使用

然后，您可以按如下方式构建项目：

mvn -Pprod package

---

我有好消息和坏消息

好消息是Config4*（我是其中的维护者）通过对自适应配置的支持巧妙地解决了这个问题。基本上，这是配置文件适应其运行环境（包括主机名、用户名、环境变量和命令行选项）的能力。有关详细信息，请阅读“入门”手册。别担心，这是一个简短的章节

坏消息是，目前，Opj4的实现只针对C++和java，所以.NET应用程序不走运。即使使用C++和java应用程序，将配置文件*改装成现有应用程序也没有实际意义。因此，我建议尝试仅在新应用程序中使用Config4*

---

尽管有坏消息，但我认为阅读Config4*文档的上述章节是值得的，因为这样做可能会为您提供一些想法，您可以根据自己的需要进行调整。

借用Jez Humble和David Farley的书“”，您可以：

• 您的构建脚本可以在构建时拉入配置并将其合并到二进制文件中
• 您的打包软件可以在打包时注入配置，例如在创建程序集、EAR或GEM时
• 您的部署脚本或安装程序可以获取必要的信息，也可以向用户索要信息，并将其传递给您的应用程序 作为安装过程一部分的部署时间
• 应用程序本身可以在启动时或运行时获取配置

他们认为在构建和编译时注入配置文件是不好的做法，因为您应该能够将相同的二进制文件部署到每个环境中

---

我的经验是，您可以将每个环境的所有配置文件（敏感信息除外）烘焙到部署文件（war、jar、zip等）中。您还可以将应用程序设计为在启动时引入一个额外的参数，以便在应用程序启动时拾取正确的配置文件集（从提取的部署文件，或者从本地/远程文件系统（如果它们是敏感的），或者从数据库）。

这很有意义！我认为应在安装/部署时选择特定于应用程序/环境的配置，并在启动/访问时应用特定于用户的配置。在Asp.net应用程序中，您可以设置部分配置文件以对应于生成类型（调试与发布）。然后，系统将选择正确的配置部分，将适当的配置/属性文件放在一起，类似于maven示例。