Where should we keep application properties file while doing build promotion using Jenkins?

We are using spring boot to develop Java backend services. application.properties file has the database configurations. We are deploying in 4 different environments (dev, test, UAT, and production). The properties files will be different for different environments. Where should we keep these files and how should do build promotion using Jenkins? We are using Apache Tomcat to deploy our WAR file.

Now we are keeping the properties file in C:\Program Files\Apache Software Foundation\Tomcat 7.0\conf directory and accessing using the following code.

@PropertySource(value = {"file:${catalina.base}/conf/application_dev.properties"})

Each time we deploy in different environments, we need to replace the respective file name application_test/uat/production.properties, commit the code and let Jenkins build and deploy. Now manually we have to keep the files in different environments too.

Please suggest how should we do it.

I disagree with @levi, you should stick to the 12 factor app method. Leaving configs in the repo scusk. Simple changes to a password or a small setting requires a commit and a pipeline rebuild. That's too much work for something so simple.

The last 3 companies I've worked for are using 'single branch' repos. There is only the master branch, and developers create 'feature' branches off of that. All the different environments are built from master.

In that case, we have a static config file, but all the values are injected by the build pipeline. You can pull them in from different sources: build server env variables, an external tool (Hashicorp Vault), or even another repo that has all the configs (this last one is least desirable).

StackExchange DevOps Q#4189, answer score: 2