I don't what is the most secured pattern to follow. Should application.properties be the prod configuration and create a application-dev.properties for development?

Or the opposite, application.properties for dev and application-prod.properties for production?

Or a mix of both, having both application-prod.properties and application-dev.properties?

CodePudding user response：

Spring will load the default application.properties file for every profile enabled.

Then the profile specific property file (ex application-dev.properties) is loaded and merged into the properties of the spring context.

So I think the best approach is:

• use the default application.properties file for properties that are common between different profiles.
• use specific property files ex application-dev.properties to define properties that are separate between environments.

Also as per documentation properties defined in profile specific application property file, are able to override properties defined under the default application.properties file. This here is what opens the door for what you mention like, having for production the default application.properties file and then each environment using it's own profile property file since that way the profile specific property file will override the properties declared in the default application.properties.

But I think that the first approach I mentioned is more clean.

CodePudding user response：

I think I saw all of those patterns in different projects. Even I can list couple more. All of them were enterprise level projects developed by mature teams.

Rather than naming patterns, there is another practice which is most important: Never include any sensitive data in codebase.

If you use yaml or property file, if you choose a naming pattern etc is just matter of choice and implementation.