这是我在各种公司发现的常见问题：
我们生产的罐子、战争和耳朵在工件中包含客户特定的配置。部署方向通常是：
* 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，我的工作是监督构建和部署。 解压缩和重新压缩这些部署容器对我来说很糟糕。它只会使部署更加困难和耗时。
在一家公司，我设置了我们的构建系统，为每个环境构建定制的罐子/战争。部署很简单，但我对此并不感到兴奋，因为这些存档的数量随着环境数量的增加而增加。另外，我不会将相同的 jar 从我的开发人员部署到 QA 再到 UAT 到生产环境。是的，这些 jar 是同时构建的，除了这些属性文件之外是相同的，但让我感到不安的是，我们在生产环境中部署的 jar 从未在我们的 UAT 或 QA 环境中直接测试过。
在我们目前的公司，我编写了自动部署脚本，手动解压缩和重新压缩这些存档文件，并修改其中的属性文件。这些脚本的维护成本很高，而且它们是我的责任，这意味着当开发人员进行一些更改（例如添加另一个属性文件）时，直到部署失败，我才会收到通知。
我不是Java开发人员，所以我不知道处理这个问题的正确方法。我最初的倾向是将所有内容放入数据库中。单个属性文件将简单地告诉应用在哪里可以找到数据库。所有值（基于环境或主机名）都将从数据库中提取。但是，开发人员告诉我，这将需要对应用程序进行大量重写，并且很难实现。（我愤世嫉俗的头脑将此翻译为您希望我们解决一个不会直接影响我的问题？没门！
我们使用Tomcat和JBoss，我想知道这些属性文件是否可以放在服务器上的其他位置，JBoss或Tomcat配置可以跟踪它们。（例如，类似于$CLASSPATH的东西）。开发人员需要为这种类型的更改做多少工作？只是确保他们在从属性文件读取时不使用绝对路径？或者，这太难做到了吗？（同样，开发人员告诉我，这也太复杂了，无法实现。
从可部署项目中删除系统特定属性文件的最简单方法是什么？您在公司如何处理此问题？
我的问题不是把我的工作典当给另一个群体。这是为了使部署更顺畅、更快捷。这将使我们能够在测试环境中部署更多内容，并且不易出错。我一直在记录部署问题，以及它如何影响我们的客户，以及修复需要多少工时。我可以说当前的系统已经崩溃了。我只是没有足够的知识来推荐某种修复方法。
配置的外部化存储是正确的想法。不过，不必是数据库。例如，这里有一篇很好的文章，提倡为此目的使用环境变量：
http://12factor.net/config
另一个（大铁）选择是使用类似Apache Zookeeper的东西
。http://zookeeper.apache.org/