How to Handle Project Configuration

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.