如何区分应用程序中的测试和生产属性？答案

【问题标题】：How to differentiate between test and production properties in an application?如何区分应用程序中的测试和生产属性？
【发布时间】：2009-07-22 19:12:19
【问题描述】：

我们正在开发一个大型 J2ee 电子销售解决方案。它有很多集成：CMS、ERP、邮件服务器等。所有这些系统都分为测试和生产环境。

我们需要使用测试配置将我们的应用程序部署到我们的测试服务器，并且当部署到我们的生产服务器时，它应该使用生产配置。我们如何让我们的应用程序选择正确的属性？

到目前为止，我们尝试过的事情是这样的：

我们所有的属性文件都包含测试属性和生产属性

test.mvxapi.server = SERV100TS
test.mvxapi.username = 用户
test.mvxapi.password = 密码
测试.mvxapi.port = 6006
test.mvxapi.cono = 600

mvxapi.server = SERV10001
mvxapi.username = 用户
mvxapi.password = 密码
mvxapi.port = 6001
mvxapi.cono = 100

读取这些属性的 Util 有一个开关：isTest()，它在键前面加上“test”。

public String getProperty(String property)
{
    return properties.getProperty(prefix + "" + property);
}

开关由我们的构建服务器创建的另一个属性设置。构建 .EAR 后，我们的生产服务器的脚本将（输入到 build.xml）“isProduction=true”注入到 system.properties。

<propertyfile file="${buildDir}/system.properties">
        <entry  key="isProduction" value="${systemType}"/>
    </propertyfile>

我不确定这是不是最好的方法。如果由于某种原因“isProduction=false”被错误地提交到我们的生产环境中，一切都变得松散了。

我读过人们在服务器本地拥有属性。但我们真的不想让文件四处散布。我们有生产服务器集群。确保每台服务器都有正确的属性文件似乎不是万无一失的

【问题讨论】：

2009 年的大小已更改 :) Spring 现在可以在配置文件中执行此操作：docs.spring.io/spring-boot/docs/current/reference/html/…

标签： java jakarta-ee

【解决方案1】：

您要避免在 EAR 中包含配置文件，这样做的问题是您需要针对不同环境使用不同的 EAR，而且更改配置文件需要重新构建。

而是将相同 EAR 部署到每个服务器，但为每个服务器配置不同的 URL 资源。 iow，将JNDI URL 资源添加到您部署到该点的所有服务器到该资源的配置文件。如果您对您的存储库具有只读 SVN 访问权限，则在 svn 存储库或您可以通过 URL 访问的任何存储库上创建配置文件。这里很酷的一点是您的所有配置都是集中的，因此管理它们很容易。

我所做的（通过使用 spring 自定义）是确保 JNDI URL 资源是可选的。因此，如果它存在，应用程序将使用它，如果不存在，则不会。无论应用程序是否存在，该应用程序都会启动。这样，即使在没有可用的 JNDI 资源的情况下运行，应用程序仍然可以工作（例如开发环境）。

【讨论】：

我将查看 JNDI url 资源。直接从 SVN 读取配置听起来不错。如果我理解正确？您如何处理对配置的更改？重启EAR？你写道你有某种故障转移。退路是什么？ EAR 中的配置文件？
回退是 EAR 中的配置文件。进一步说明...这是加载配置文件的顺序 1. 默认配置文件 2. 通过主机名命名的配置文件（特定于主机名，也在 EAR 中）。因此，您可以轻松配置在不同节点上运行的应用程序，例如，每个开发人员都可以配置他的环境。 3. 通过 jndi 查找配置文件最后加载的值是它使用的值，2 和 3 是可选的。要刷新配置，一旦更改，我们只需重新启动 EAR（因为我们使用的是 spring，所以在启动时创建应用程序上下文时会读取配置文件）。

【解决方案2】：

您部署了 EAR？然后把需要的属性放到JNDI里面。

【讨论】：

这可行。但是，要让所有这些属性在许多服务器上保持同步似乎需要大量的手动工作。您将如何对它们进行版本控制？
取决于您使用的服务器。我相信例如JBoss 允许通过部署类似于 EAR 和 WAR 的档案来配置 JNDI 条目，这允许您使用与主应用程序相同的过程。否则编写脚本，并对脚本进行版本控制。
此外，如果您为测试和生产构建单独的版本，您将在生产中部署未经测试的代码，因为您已经测试了不同的构建。

【解决方案3】：

我不能说这是否是最好的方法，但是，我们所做的是包含一个客户端和服务器 jar，它们相应地容纳属性。然后，我们将这些 jar 包含在 EAR 文件中。因此，在我们的构建过程中，我们会为我们要部署到的环境包含适当的（QA、TEST、PROD）jar。

缺点是我们必须管理三组环境 jar，构建团队必须小心不要部署不正确的。事实上，曾经有一次我们将一个 PROD jar 部署到我们的 QA 环境中，并且 QA 数据正在投入生产......是的，这很糟糕，而且是一个需要清理的大混乱。

我会关注这个讨论，因为我经常想知道我们如何才能让这个过程变得更好/更安全。很棒的帖子 +1

【讨论】：

【解决方案4】：

在以前的 J2EE 项目中，我们一直在这样做。构建过程（一个 ant 脚本）将正确的配置文件放在一起，将它们添加到某个 jar 中，然后将其放入 EAR 文件中用于生产环境、测试、培训、QA 等。

EAR 文件的文件名中包含了目标环境的名称，因此基本上不可能将文件部署到错误的环境中。如果我们为目标 156p2（工厂 156，生产环境 2）构建，这将是 EAR 文件的文件名的一部分，并且 ant 将包含 config_156p2.xml。如果目标不正确，EAR 文件的名称就会出错，作为最后的故障保险，部署它的人会注意到。

构建文件必须包含以下内容：为每个环境启动构建的一个 ant 目标，这将设置一个属性，告诉 ant 包含哪个配置文件。

EAR 文件之间的唯一区别就是配置文件。其他一切都是一样的。当然，也有可能有人在某个环境的配置文件中写入了错误的值。然而，在实践中，这在几年内从未发生过，即使对于一些相当初级的开发人员和大约 15 个目标环境（不同国家的不同测试、QA、培训和生产服务器）也是如此。

【讨论】：

【解决方案5】：

我们的项目中有 3 个用于此目的的文件夹，每个文件夹都包含配置文件（文件夹之间的文件名相同）：

个人：包含测试数据库、服务器等的路径
test：包含与我的同事共享的服务器的路径
生产：包含...你猜对了

当我构建我的项目时，我将合适的配置文件添加到 Intellij Idea 项目构建中，在所需的模块中，这基本上意味着我正在向项目结构添加一个不同的文件夹，但是因为文件名相同，所以更改只是配置文件属性。

【讨论】：

【解决方案6】：

非常旧的帖子仍在回复，以防有人检查它。在每个应用程序服务器中，您可以设置系统属性，例如

Wildfly 管理控制台 --> 配置 --> 系统属性

在那里我添加了一个变量SERVER_ENVIRONMENT，其值为DEV/UAT/PROD。

在我的 java 代码中，我使用： System.getProperty ("SERVER_ENVIRONMENT")

这给了我来自服务器的价值。

【讨论】：

【解决方案7】：

就像@Alberto-Zaccagni 所说，您可以拥有单独的文件夹，其中包含仅存在于各自环境中的属性文件。您的代码检查是否存在以 PROD 然后 UAT 然后 DEV 开头的文件夹，当它发现路径存在时，它会使用那里的属性文件。

【讨论】：