如何在Gradle构建的Spring Boot 2.0.0 Tomcat部署WAR中区分开发生产环境？

Hey there! I’ve dealt with this exact scenario before—let’s break down the most straightforward, practical ways to handle environment-specific parameters when deploying your Spring Boot WAR to Tomcat, using Gradle.

方法1：使用Spring Profiles（最推荐） #

Spring Boot’s built-in profile system is made for this kind of environment switching. Here’s how to set it up:

1. 创建环境专属配置文件
   In your src/main/resources directory, create two separate config files:

   • application-dev.properties (or .yml for YAML lovers):

     myparam1=devvalue
     # Add other dev-only settings here, like database URLs or debug flags
     

   • application-prod.properties:

     myparam1=prodvalue
     # Add production-specific settings here (e.g., stricter logging, production DB credentials)
     

2. 激活对应环境的Profile
   You have a few options to tell Spring which profile to use:

   • Pass via Tomcat startup parameters (most flexible for WAR deployment):
     Edit Tomcat’s bin/catalina.sh (Linux/macOS) or catalina.bat (Windows) to add a system property:

     # Linux/macOS: Add this line to catalina.sh
     JAVA_OPTS="$JAVA_OPTS -Dspring.profiles.active=prod"
     
     # Windows: Add this line to catalina.bat
     set JAVA_OPTS=%JAVA_OPTS% -Dspring.profiles.active=prod
     

     Just swap prod with dev when deploying to your development Tomcat instance.

   • Set a default profile in main config:
     Add this line to your root application.properties to use dev mode by default:

     spring.profiles.active=dev
     

     You can still override this with the Tomcat startup parameter for production.

3. Gradle打包注意事项
   Your bootWar task in build.gradle doesn’t need extra tweaks—all profile config files will be packaged into the WAR. This lets you use one WAR file across all environments, which is super convenient.

方法2：Gradle资源过滤（构建时固定环境） #

If you prefer to build environment-specific WARs directly (no runtime switching), use Gradle’s resource filtering:

1. Add placeholders to your main config
   In application.properties, replace hardcoded values with placeholders:

   myparam1=${env-specific.value}
   

2. Configure Gradle to replace placeholders
   Add custom WAR tasks to your build.gradle for each environment:

   tasks.register('devWar', BootWar) {
       group = 'build'
       description = 'Builds a WAR optimized for development'
       processResources {
           filesMatching('application.properties') {
               expand('env-specific.value': 'devvalue')
           }
       }
   }
   
   tasks.register('prodWar', BootWar) {
       group = 'build'
       description = 'Builds a WAR optimized for production'
       processResources {
           filesMatching('application.properties') {
               expand('env-specific.value': 'prodvalue')
           }
       }
   }
   

   Run ./gradlew devWar or ./gradlew prodWar to generate the corresponding WAR file. No extra setup needed when deploying to Tomcat—each WAR has its own baked-in config.

额外小技巧：Tomcat上下文参数 #

If you don’t want to modify Tomcat startup scripts, you can set parameters directly in Tomcat’s conf/context.xml:

<Context>
    <Parameter name="myparam1" value="prodvalue" override="false"/>
</Context>

Then bind it in your application.properties:

myparam1=${myparam1}

This works well if you manage separate Tomcat instances for each environment, but it’s less flexible than using profiles.

To sum up: Spring Profiles are the way to go for most cases—one WAR, multiple environments, no re-building needed. Gradle resource filtering is great if you need strictly separated, environment-locked WAR files.

内容的提问来源于stack exchange，提问作者ace