通过 Spring 或通过 Maven/Gradle 等构建工具的配置文件有什么区别

Question

We are currently developing a Spring Boot based application and we have a QA and a Prod environment to deploy. I suggested that having different app properties file for different environments and then using -Dspring.profiles.active in a Docker compose file would be a good solution for profiling.

But, my colleague says that having a build tool based profiling would be a better idea. Something like this - https://mkyong.com/maven/maven-profiles-example/

Please help me understand the advantages and disadvantages between these two ways as I am not finding sufficient reading materials online.

Answer 1

To compare Spring and Mvn/Gradle is to compare 2 tools designed for different things.

Both however, allow you to feed configuration through different mechanics. Spring profiles are intended to be used for deploying applications in different environments, so in terms of use-case and intended use, what you described fits in to this. (Ref: https://docs.spring.io/spring-boot/docs/1.2.0.M1/reference/html/boot-features-profiles.html )

Here's a couple of advantages of using Spring profiles over a build tool's config I thought of:

• Can switch profile without rebuilding the application
• Can debug the application itself rather than looking at the build config, which should be easier

Answer 2

I think the best approach to change configuration based on environment is to use an external config server where the service will connect at startup and fetch the configuration that applies to the environment where the app is deploying.

For example, you can use spring-cloud-config server and create different configuration files for each environment and when the service deploys, use spring profiles to know what is the environment in which the application is being deployed and get the correct configuration:

https://cloud.spring.io/spring-cloud-config/reference/html/

Answer 3

With Mvn/Gradle profiles, the profile is selected at build time. So you will need to rebuild your project for Prod after it's accepted on QA.

With Spring, the profile is selected at runtime. You can deploy the same WAR file or Docker image on QA or on Prod, but you only need to change the runtime profile, eg via the command line -Dspring.profiles.active=... or via an environment variable SPRING_PROFILES_ACTIVE=..., and Spring will select either application-qa.properties or application-prod.properties during startup.

Having the same Docker image on Prod or QA is definitely better, I think. The downside of using Spring profiles that you include the property sets for both QA and Prod inside the image, and when you want to change either one, you will have to rebuild the whole Docker image.

A third option is not to use profiles at all, but externalize all properties that are not the same for QA or Prod. For example, set spring.datasource.url, username, password, etc, via a deploy descriptor rather than include it in your docker image. This way, you can reuse the same Docker image for any environment, and reconfigure it on the fly. Additionally, you can keep production passwords secret from developers if you want.

What @JArgente suggest goes even a step further: read the properties from an external service at startup time. But that may be overkill, if you can do it via Kubernetes environment variables.