Should platform specific config be in app package?

Question

At my place of work a few people think it's OK to have platform specific configuration items (things like back-end host names/IP addrs, DB connection details etc) imbedded (as .properties file(s) ) in application packages (a Web App .war file). I think this is a bad bad thing for the following reasons:

• there needs to be a separate package for each target platform (could be a dev lab, a model lab, production etc)
• build overhead - build scripts typically build a set of target app packages (they all get built at the same time on the assumption that this version is the final version)
• management effort (eg source/version control) of configuration items needs (in theory it means even userid/passwords of customer systems is kept)
• one can't be sure that the version of the package is correct (checksum useless) - is the executable part of the package that was tested in the lab the same as that moved into production?

A consequence of this approach is that (for Java Web App), in a customer environment, administrators deploy the package, shutdown the app server, copy platform specific configs over the top of those that were imbedded in the package, and restart the app server. Painful.

Perhaps a better approach is to externalise platform specific configuration items - do not have them imbedded in the .war file, and do not have the application reference them in the expanded .war file directory tree. Instead, have configuration items in a "..\conf" directory outside the application directory. This has the benefits of:

• one and only one application package for the executable component of the application
• shorter build overhead (compared to above)
• no knowledge of "customer" platform specific configs (userids/passwords)
• auditability (able to do a checksum on an app package, do the same in a lab or on customer platform, and have a high level of confidence that executables are the same) - "what we tested with is what you have"
• deployment is a much shorter process - depending on app server capability, dump the app .war file in the relevant directory and, if no config changes (often the case), bounce the app server.

This approach does need the application to be able to reference a file outside the application directory. There is a small security consideration on that. App server environment variables facilitate apps to be able to locate files outside their app directory (or CLASSPATH).

Am looking for the community to vote accordingly. I can then go back to my work collegues and say "don't just listen to me, see what the Stackoverflow community reckons."

Answer 1

I have seen three patterns:

1. Config in the app. New build for each environment
2. Configs (plural) in the app. Appropriate build chosed by some emvironmental control
3. Configs separate from App. Config selected by some environmental control.

This article describes one possible way to implement approach 3.

My opinion: Option 1 requires new builds for each environment, this just doesn't fit my thought about promotaing apps through stages of test.

Options 1 and 2 both suffer from the problem of how to change a config item after release. A new release of the app to change a diagnostic level? Surely not.

Option 3 is somewhat more complex, a feew details to iron out in a clustered environment. But I see major benefits. I would be very interested to see the curcumstances under which options 1 or 2 are considered better.