特定于环境的构建与加载特定于环境的属性答案

【问题标题】：Environment specific build vs loading environment specific properties特定于环境的构建与加载特定于环境的属性
【发布时间】：2011-06-28 10:55:33
【问题描述】：

构建的一个选项是在构建时打包特定于环境的属性（例如使用 maven 配置文件）

另一个选项是在您的生产环境中设置-Denv=production，并在启动时加载/${env}/config.properties。（例如 spring 允许这样做，但可以手动完成）

我都用过。前者意味着无需额外的环境配置。后者允许在多个环境中使用相同的构建。

问题：任何其他重要的优点/缺点，或者选择哪种方法几乎相同？

【问题讨论】：

我标记了 java，因为我上面的例子是基于 java 的。但也欢迎与语言无关的答案。
这里我们别无选择：我们不能在 PROD 中放入未在 PREPROD 中接受的 .war。这必须是完全相同的.war。我们基本上使用“选项 3”，即“matt b”正在使用的选项。顺便说一句，我们无权访问生产环境的凭据：所以我们的 .war 知道在哪里可以找到配置文件，但我们开发人员不应该这样做。

【解决方案1】：

在我看来，每个环境有不同的输出是一个主要缺点，因为这意味着您需要构建应用程序的 N 个副本，运行相同的构建命令 N 次，等等。在您提供的地方很容易出错“开发”版本到 QA 站点等。

我很喜欢第三种选择——将配置值存储在服务器本身上，与应用程序分开，然后编写应用程序以知道在哪里可以找到这些配置文件，或者你有某种脚本，通过将其配置文件中的标记替换为外部文件中的规范值来“重新配置”应用程序。

通过这种方式，您可以为所有环境提供相同的二进制文件，并且可以轻松地将外部配置置于源代码控制之下（例如，每个环境一个文件），以便审核更改，自动传播更改等。

如果您在一个开发人员与“操作”应用程序或负责不同环境的团队分开的大型组织中工作，这也是一个方便的选择 - 因为使用这种方法，开发人员可以知道什么进行配置，但另一组负责在每个主机上提供的配置值。

【讨论】：

【解决方案2】：

我有 2 个构建，一个生成二进制文件（war 文件，没有任何服务器特定配置），另一个项目为每个环境环境生成一些属性文件。部署过程获取战争和相关配置文件并发挥其魔力。

我不认为从二进制文件中的所有环境传送配置是一个好习惯......但主要是因为我认为有可能使用错误的选项启动应用程序，然后开发应用程序突然尝试连接到生产环境。

另一件事是，一些属性，例如数据库连接详细信息或支付网关密码，保存在由运营/托管服务团队拥有的不同配置文件中。因为我们不希望开发人员或流氓 DBA 与生产数据库发生冲突。

【讨论】：