Spring Boot allows you to have one common configuration file (application.properties) and then multiple other files, each specific to a profile (application-${profile}.properties).

For instance:

• application.properties – Common configuration
• application-dev.properties – Configuration for dev profile
• application-ci.properties – Configuration for ci profiles

If your application runs with “ci” profile for instance, the default configuration file as well as the ci configuration file (which would contain the datasource configuration properties for ci profile) will be loaded.

To switch profiles you can use one of the following options:

• JVM property: -Dspring.profiles.active=ci
• Command line switch: --spring.profiles.active=dev

For unit tests you can use @ActiveProfiles("test") annotation on your test classes to tell Spring that unit tests should be run with test profile.

Also if you don’t want to store production database credentials along with your source code, you can specify external configuration file when you deploy your app in production:

• Using command line switch: --spring.config.location=/srv/myapp/config.properties
• Using a JVM property: -Dspring.config.location=/srv/myapp/config.properties

---

 

I think I’ll create the different properties files for dev-h2 database, and test-MySQL database. Then change based on Profile. My only question is what to do about the pom.xml file. Do I include h2 and mysql?

Hmmm… some people seem to add both. If the application is configured to use MySQL, then it’ll ignore the h2 in the pom.xml file. However, another suggested using Maven Profiles to build different things as you don’t have to package up unused jars to ship to production, and this minimizes any chance of an in-memory database starting up in production. It also gives you the option of minimizing the static resources for speed. I think the gzip compression is done on the server.

http://maven.apache.org/guides/introduction/introduction-to-profiles.html

I think I’ll do both.