这是我在多家公司发现的常见问题：
我们生产 jars、wars 和 ears，其中包含工件内的客户端特定配置。部署方向通常是：
* Unzip the war/jar/ear
* Go to directory that contains the configuration properties.
* Rename config-prod3.properties to config.properties (or even worse, edit the config.properties file directly)
* Remove the rest of the configuration properties
* archive the deployable back up
* Now, copy it to its deployment location.
作为 CM，我的工作是监督构建和部署。解压缩和重新压缩这些部署容器让我觉得很糟糕。它只会使部署更加困难和耗时。
在一家公司，我设置了构建系统来为每个环境构建定制的 jars/wars 。部署很简单，但我对此并不感到兴奋，因为这些档案的数量随着环境的数量而增加。另外，我没有将相同的 jar 从我的开发人员部署到 QA 到 UAT 到生产环境。是的，这些 jars 是同时构建的，除了这些属性文件之外都是相同的，但让我感到不安的是，我们在生产环境中部署的 jar 从未在我们的 UAT 或 QA 环境中直接测试过。
在我们目前的公司，我编写了自动部署脚本，可以手动解压缩和重新压缩这些存档文件，并将其中的属性文件放入其中。这些脚本的维护成本很高，而且它们是我的责任，这意味着当开发人员进行一些更改（例如添加另一个属性文件）时，我不会在部署失败之前收到通知。
我不是 Java 开发人员，所以我不知道处理这个问题的正确方法。我最初的想法是将所有内容都放入数据库中。单个属性文件将简单地告诉应用程序在哪里可以找到数据库。所有值（基于环境或主机名）将从数据库中提取。但是，开发人员告诉我，这将需要对应用程序进行大量重写，并且实施起来太困难了。（我愤世嫉俗的想法将此翻译为您希望我们解决一个不直接影响我的问题？不可能！）。
我们使用 Tomcat 和 JBoss，我想知道这些属性文件是否可以放在服务器上的其他位置，并且 JBoss 或 Tomcat 配置可以跟踪它们。（例如，类似 a 的东西$CLASSPATH）。开发人员需要为这种类型的更改做多少工作？只是确保他们在从属性文件中读取时不使用绝对路径？或者，这太难了？（同样，开发人员告诉我这也太复杂而无法实现。）
从可部署工件中删除系统特定属性文件的最简单方法是什么？你在你的公司做什么来处理这个问题？
我的问题不是将我的工作抵押给另一个团队。这是为了使部署更顺畅、更快。这将使我们能够在我们的测试环境中部署更多，并且更不容易出错。我一直在记录部署问题，以及它如何影响我们的客户，以及修复需要多少工时。我可以提出当前系统已损坏的论点。我只是没有足够的知识来推荐某种修复方法。