Every web project needs some environment-specific configurations. Database credentials, root url, smtp settings, to name a few. It’s a recurring question on stackoverflow, and I’ve seen a lot of variations on the topic, and here I’ll describe the one that I think is best.
- put all such properties in a .properties file (for example application.properties)
- have that application.properties sitting outside the web application. It is not bundled with the build
- provide a command-line option that indicates where that file is located. For example
-Dconfig.location=/home/you/config
- on application startup (in a ServletContextListener usually) load the file and put it in a map. Can be java.util.Properties or a HashMap
- for spring users – use
<context:property-placeholder-configurer location="file://${config.location}/application.properties"
. Other frameworks will likely have some mechanism for loading such global properties - hold a skeleton properties file in the SCM repository. It should contain all properties, but their values are irrelevant – they will change on each environment
- the ops team is likely to benefit from versioning different environment configurations (production, qa, stage), so a separate /config folder/subproject can be created and all environment-specific properties can be stored there. When adding a property developers should go and update all files accordingly
- properties that are not dependent on the environment, but are still global for the project, can be stored within the project (src/main/resources for maven), and committed to SCM. They can be merged with the external properties on startup (merged in memory, that is)
- most of the externalizable properties can have reasonable defaults – the smtp server of the company, the database driver, etc. They can be placed in a
application-defeault.properties
within the project, and the external file can override them. This is just an option – if you are going to have a file committed in the repository with those reasonable defaults, and each environment to use that file as a basis, it’s virtually the same
Developers can easily run their projects that way. Ops can easily deploy builds on different environments. The build remains environment-agnostic.
Every web project needs some environment-specific configurations. Database credentials, root url, smtp settings, to name a few. It’s a recurring question on stackoverflow, and I’ve seen a lot of variations on the topic, and here I’ll describe the one that I think is best.
- put all such properties in a .properties file (for example application.properties)
- have that application.properties sitting outside the web application. It is not bundled with the build
- provide a command-line option that indicates where that file is located. For example
-Dconfig.location=/home/you/config
- on application startup (in a ServletContextListener usually) load the file and put it in a map. Can be java.util.Properties or a HashMap
- for spring users – use
<context:property-placeholder-configurer location="file://${config.location}/application.properties"
. Other frameworks will likely have some mechanism for loading such global properties - hold a skeleton properties file in the SCM repository. It should contain all properties, but their values are irrelevant – they will change on each environment
- the ops team is likely to benefit from versioning different environment configurations (production, qa, stage), so a separate /config folder/subproject can be created and all environment-specific properties can be stored there. When adding a property developers should go and update all files accordingly
- properties that are not dependent on the environment, but are still global for the project, can be stored within the project (src/main/resources for maven), and committed to SCM. They can be merged with the external properties on startup (merged in memory, that is)
- most of the externalizable properties can have reasonable defaults – the smtp server of the company, the database driver, etc. They can be placed in a
application-defeault.properties
within the project, and the external file can override them. This is just an option – if you are going to have a file committed in the repository with those reasonable defaults, and each environment to use that file as a basis, it’s virtually the same
Developers can easily run their projects that way. Ops can easily deploy builds on different environments. The build remains environment-agnostic.
Recent Comments