我曾多次遇到同样的问题，我想了解其他人对这个问题的看法： 假设我们将 Spring 应用程序打包为.war文件，我们想运行它几种环境。 （开发/测试/预生产/生产/等）

为了访问应用程序所需的基础设施（数据库/网络服务等），我们将访问信息存储在配置文件中，一些业务配置也位于这些文件中。 假设我们使用。特性用于此目的的文件（因为我们在 war 中有一个 spring 应用程序，并且我们喜欢由 appcontext 中的单行读取属性） 并且还假设在不同的环境中我们没有相同的应用程序服务器/servlet 容器。 （例如：开发、测试：jetty、预生产：tomcat、生产：glassfish）

我通常做的是创建多个Maven 配置文件，每个环境一个，每个环境的相应文件中所需的配置。

最近，我遇到了一位运营人员提出的问题： “那么，如果数据库在预生产环境中发生更改，我们真的必须在构建服务器上生成具有适当配置文件的新构建吗？” 我回答“不，您实际上可以转到 .../webapps/currentApp/WEB-INF/classes/config/application.properties 并更改那里的值，然后重新启动容器”

我们提出了一个解决方案，可以解决此问题的某些方面： 使用 Maven 组装插件，我们嵌入了 Jettyinside战争使其可用作“可执行”战争，也使我们有可能拥有全局配置 XML， 嵌入式 Jetty 的启动程序在展开的 war 目录中创建/修改适当的 .properties 文件，然后才启动应用程序。

但同样，如果您想使用 Jetty 以外的其他任何东西，这并不能解决问题。

大家遇到同样的情况都是怎么处理的呢？

环境变量、外部配置文件

我们有类似的东西，一个使用 Spring 在 Tomcat/Weblogic 中运行的 Web 应用程序。 我们所做的就是定义一个环境属性 https://en.wikipedia.org/wiki/Environment_variableCONFIG_PATH 并将所有 XML（包括 spring 配置）和属性文件放入该目录中。

我们有多个属性文件（每个环境），我们将其作为 tar 文件发送。 Web 应用程序从 CONFIG_PATH 目录加载所有 Properties/Spring 配置文件。该变量被定义为各自环境中的环境变量

这样我们就不会触及 WAR 文件，也不会为环境构建单独的 WAR。想想这个场景：构建了 QA 和 PROD WAR 文件，QA 测试了 QA war 文件，PROD WAR 部署在 PROD 中，但有些东西爆炸了:(

我们做如下事情：

在 spring 配置 xml 中，我们定义：

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="order" value="0"></property>
    <property name="locations">
        <list>
            <value>file:${CONFIG_PATH}/App.properties</value>
        </list>
    </property>
</bean>

像往常一样在 spring 配置中引用所有变量。

在 web.xml 中我们定义 spring 配置如下：

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>file:${CONFIG_PATH}/**/spring-config.xml
    </param-value>
</context-param>

QA/PROD 团队使用相应的环境文件部署相同的工件。如果有什么东西爆炸了，我们知道这只是环境问题。属性被搞乱了。 华泰