构建的一个选项是在构建时打包特定于环境的属性（例如使用maven配置文件）
另一种选择是在生产环境中设置-Denv=production，并在启动时加载/${env}/config.properties。 （例如，弹簧允许，但可以手动完成）
我用过两者。前者意味着没有额外的环境配置。后者允许在多个环境中使用相同的构建。
问题：任何其他重要的利弊，或几乎相同的方法将被选择？
相关：Load environment-specific properties for use with PropertyPlaceholderConfigurer?
答案 0 :(得分：6)
在我看来，每个环境有不同的输出是一个主要的缺点，因为这意味着你需要构建应用程序的N个副本，运行相同的构建命令N次，等等。很容易遇到你给出的错误“开发”版本到QA网站等。
我喜欢它之间的第三个选项 - 将配置值存储在服务器本身，与应用程序分开，然后编写应用程序以了解在哪里可以找到这些配置文件或者您有一些脚本可以通过用外部文件中的规范值替换其配置文件中的标记来“重新配置”应用程序。
通过这种方式，您可以为所有环境提供相同的二进制文件，并且可以轻松地将外部配置置于源代码管理下（例如，每个环境一个文件），以便可以审核更改，可以自动传播更改等。 / p>
如果您在开发人员与“操作”应用程序或负责不同环境的组分开的大型组织中工作，这也是一个方便的选择 - 因为使用此方法，开发人员可以知道什么进行配置，但另一组负责在每台主机上提供配置值。
答案 1 :(得分：1)
我有2个版本，一个生成二进制文件（一个war文件，没有任何特定于服务器的配置），另一个项目为每个环境环境生成一些属性文件。 部署过程采用战争和相关的配置文件并发挥其魔力。
我不认为从二进制文件中的所有环境中发送配置是一种很好的做法...但主要是因为我认为有可能使用错误的选项启动应用程序，并且突然启动应用程序尝试连接到生产。
另一个原因是某些属性（如数据库连接详细信息或支付网关密码）保存在操作/托管服务团队拥有的其他配置文件中。因为我们不希望开发人员或流氓DBA对生产数据库进行弹道导弹。