这是我在不同公司发现的一个常见问题：
我们生产包含工件内部客户特定配置的罐子，战争和耳朵。部署方向通常是：
* 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 / wars 。部署很简单，但我对此并不感到兴奋，因为这些档案的数量随着环境的数量而增加。另外，我没有从我的开发人员向QA部署相同的jar到UAT到生产环境。是的，罐子是同时建造的，除了这些属性文件外，它们是相同的，但是让我感到不安的是我们在生产中部署的罐子从未在我们的UAT或QA环境中直接测试过。
在我们当前的公司，我编写了自动部署脚本，手动解压缩并重新压缩这些存档文件，并将属性文件固定在其中。这些脚本的维护成本很高，而且它们是我的责任，这意味着当开发人员进行一些更改（比如添加另一个属性文件）时，在部署失败之前我不会得到通知。
我不是Java开发人员，所以我不知道 正确的 方法来处理这个问题。我最初的倾向是将所有内容都放入数据库中。单个属性文件将告诉应用程序在何处查找数据库。将从数据库中提取所有值（基于环境或主机名）。但是，开发人员告诉我这将需要对应用程序进行大量重写，并且实现起来太困难了。 （我的愤世嫉俗的思想将其翻译为你希望我们解决一个不会直接影响我的问题吗？没办法！）。
我们使用Tomcat和JBoss，我想知道这些属性文件是否可以放在服务器的其他位置，而JBoss或Tomcat配置可以跟踪它们。 （例如，像$CLASSPATH）。开发人员需要为此类变更做多少工作？从属性文件中读取时，确保它们不使用绝对路径？或者，这太难了吗？ （同样，开发人员告诉我，这也太复杂了。）
从可部署工件中删除系统特定属性文件的最简单方法是什么？贵公司如何处理这个问题呢？
我的问题不是将我的工作打入另一个群体。这是为了使部署更顺畅，更快捷。这将允许我们在我们的测试环境中部署更多，并且不会出错。我一直在记录部署问题，以及它如何影响我们的客户，以及修复需要多少工时。我可以提出当前系统被打破的论点。我只是没有足够的知识来推荐某种修复方法。
答案 0 :(得分：0)
配置的外化存储是正确的想法。不过不必是数据库。例如，这是一篇很好的文章，主张为此目的使用环境变量：
另一个（大铁）选项是使用Apache Zookeeper
之类的东西