Making the Case For Externalizing Application Configurations

Background

What do I mean by externalizing? I really mean addressing separation of concerns and making an application more portable. If you think about it, a configuration is a module that other modules in the application depend on. By separating the concerns or behaviors of an application that varies between development, test, and production environments, you can more easily manage and possibly reuse the configuration and not repeat yourself (DRY).

Some Real-Life Examples

Another example where properties are not externalized but should be is the situation where you have to rebuild an application in order to deploy it in another environment. The reason for this is that the current process and/or build script takes care of packaging the correct properties for a specific environment. Generally, you don’t want to have to rebuild an entire application just so that you can promote it from one environment to another. By externalizing the environment-specific properties (such as database configurations), you not only don’t have to rebuild the application again but you also simplify the build script.

So these are common scenarios that could be simplified by relocating or “externalizing” configurations somewhere outside the packaged application.

Advantages

1. Simplify integration testing. By separating the configuration information from the rest of the application, you can more easily do integration testing.
2. Decrease the time it takes to fail over to contingency systems.
3. Easier reuse. Let's say you have more than one application that uses some of the same properties all the time like a string to represent your company's name. A "common" properties file could be externalized and centralized so all the applications would have access to that property.
4. Decrease the file size of packaged applications. This becomes more important if you have a huge number of properties files that don't change often.

What Properties Should be Externalized

1. Database configurations. Database settings are almost always different depending on which environment your application is deployed in.
2. Information used to connect to external systems. For example, information used to connect to external JMS queues or Web services.
3. File paths needed by the application that are specific to each environment.

What Properties NOT to Externalize?

1. Properties that are environment-agnostic. For example, if you just have a few properties files that are used for internalization and the content is the same regardless of where the application is installed.
2. Properties that tend to change for every application release. For example, a version number that needs to be incremented for every release.