Java Developer

Configuration files stored in revision control system over external ones.

Almost every application depends on the environment where is executed. Database URLs, storage paths, external services or some credentials and codes have to be somehow provided, depending on execution place. I would like to show you two approaches here and explain why the second one is better.

Configuration files stored in home directory

It is a tempting vision. You are creating a single configuration file in each server box. Each developer can create this file also on local box in order to override some configuration. Your application during runtime will look inside the config file located in the home directory and you can manage different variables for each machine. It should work, right? Yes, but you have to remember about:

Configuration files stored as part of revision control system

There is, however different way of doing this. You can store configuration file along with your source code:

/src/config/config.properties
/src/config/dev/config.properties
/src/config/dev-john/config.properties
/src/config/dev-peter/config.properties
/src/config/prod/config.properties

Then you can load your files using specific app environment variable:

/src/config/config.properties
/src/config/{APP_ENV}/config.properties

On target machine you would need to setup single environment variable only:

set APP_ENV=dev

Why revision control system is the much better approach?

Let’s try to compare points from above. How it is going to change when the configuration is stored in version control.


Like it? Share it on , , ,

About the author

Grzegorz Gajos, Software Architect with international consulting and programming background. Co-founder of Open Tangerine Software House. Quality evangelist. An experienced entrepreneur, out of the box thinker and problem solver.