Java 特定于环境的生成与加载特定于环境的属性

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

另一个选项是在生产环境上设置

-Denv=production

，并在启动时加载

/${env}/config.properties

。（例如，spring允许这样做，但可以手动完成）

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

问题是：是否还有其他重要的优点/缺点，或者选择哪种方法实际上是相同的

---

相关：

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

还有第三种选择，我是其中的一员——将配置值存储在服务器上，与应用程序分开，然后编写应用程序以知道在哪里可以找到这些配置文件，或者您有某种“重新配置”的脚本通过将其配置文件中的令牌替换为外部文件中的规范值来启动应用程序

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

---

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

我有两个版本，一个生成二进制文件（一个war文件，没有任何特定于服务器的配置），另一个项目为每个环境生成一些属性文件。 部署过程使用war和相关配置文件，并发挥其神奇作用

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

---

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

我标记了java，因为我上面的示例是基于java的。但语言不可知论的答案也是受欢迎的。在这里，我们没有选择：我们不能投入一场在prepod中没有被接受的战争。这肯定是一样的，战争。我们基本上使用“选项3”，即“matt b”正在使用的选项。顺便说一句，我们无法访问生产环境的凭据：因此我们的.war知道在哪里可以找到配置文件，但我们开发人员不应该这样做。