Properties 在JAR和WAR中摆脱特定于环境的配置

这是我在多家公司发现的一个常见问题：

我们生产的jar、war和ear在工件内部包含特定于客户端的配置。部署方向通常为：

* 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/war。部署很简单，但我对此并不感到兴奋，因为这些归档文件的数量随着环境数量的增加而增加。另外，我没有将同一个jar从我的开发人员部署到QA，从UAT部署到生产环境。是的，jar都是在同一时间构建的，除了这些属性文件之外都是相同的，但让我感到不安的是，我们在生产环境中部署的jar从未在我们的UAT或QA环境中直接测试过

在我们目前的公司，我编写了自动部署脚本，可以手动解压缩和重新压缩这些归档文件，并在其中存储属性文件。这些脚本的维护成本很高，这是我的责任，这意味着当开发人员进行一些更改（如添加另一个属性文件）时，我在部署失败之前不会得到通知

我不是Java开发人员，所以我不知道正确的处理方法。我最初的倾向是把所有的东西都放进数据库。一个属性文件将简单地告诉应用程序在哪里可以找到数据库。基于环境或主机名的所有值都将从数据库中提取。然而，开发人员告诉我，这将需要对应用程序进行大量的重写，并且很难实现。我愤世嫉俗的想法将此理解为你希望我们解决一个不会直接影响我的问题？不可能

我们使用Tomcat和JBoss，我想知道这些属性文件是否可以放在服务器的其他位置，JBoss或Tomcat配置是否可以跟踪它们。例如，类似于$CLASSPATH的东西。对于这种类型的更改，开发人员需要做多少工作？只是确保他们在读取属性文件时不使用绝对路径？或者，这太难了吗？同样，开发人员告诉我，这也太复杂，无法实现

从可部署构件中删除系统特定属性文件的最简单方法是什么？你在公司做什么来处理这个问题

---

我的问题不是把我的工作丢给另一个小组。这是为了使部署更顺利、更快。这将允许我们在测试环境中部署更多，并且不太容易出错。我一直在记录部署问题，以及它如何影响我们的客户，以及修复需要多少工时。我可以提出这样的论点，即目前的体制已经崩溃。我只是没有足够的知识来推荐某种修复方法。

配置的外部化存储是正确的想法。但不必是数据库。例如，这里有一篇很好的文章，提倡为此目的使用环境变量：

另一个重要的选择是使用类似ApacheZooKeeper的东西

---

我找不到任何环境变量。它们根本不稳定。此外，当两个或多个应用程序在同一环境中运行时，您会怎么做？我的主要问题是从我们现在所面临的对我和IT来说都是一个巨大的痛苦转变为一些使我们的工作更容易的事情，但是没有大规模的编程更改。Zookeeper是一个很好的方法，但这涉及到设置Zookeeper并让我们的程序设置使用它。它们和使用它们的过程一样稳定。很多应用程序，很多流程。我正在和Zookeeper做一些初步的基础工作。我们现在不会替换所有属性文件，只替换在不同环境中变化的内容。我正在研究编写一个可以替换Properties类的类。这样，开发人员可以简单地替换类，但方法保持不变，因此编程更改更少。现在的问题是我们如何维护动物园。使用属性文件很容易。当程序更改时，属性文件也会更改。现在，我们必须在Zookeeper发布时对更改进行计时。我们会想办法的。