如何处理工程的配置文件

How to Handle Project Configuration

August 26, 2011

Every web project needs some environment-specific configurations. Databasecredentials, root url, smtp settings, to name a few. It’s a recurring questionon stackoverflow, and I’ve seen a lot of variations on the topic, and here I’lldescribe 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 deploybuilds on different environments. The build remains environment-agnostic.