What's the best practice for handling system-specific information under version control?

Question

I\'m new to version control, so I apologize if there is a well-known solution to this. For this problem in particular, I\'m using git, but I\'m curious about how to deal wit

Answer 1

Do not EVER hard-code configuration data like file system paths and force multiple deployments to match. That is the dark side, where there is much SUFFERING.

I find it useful and easy to build my systems to support multiple configurations easily, and I routinely commit configuration files into source control side-by-side, but production's is obfuscated (no real passwords) and development's is templated (so a checkout can't overwrite a developer's configuration). The code is always packaged in a configuration-neutral manner--the same binary can be deployed anywhere.

Unfortunately, most language/development platforms do not readily support this (unlike Ruby on Rails). Therefore, you have to build it yourself, to varying degrees.

In general, the basic principle is to incorporate indirection into your configuration: specify not the configuration, but how to find the configuration, in your code. And generally invoke several indirections: user-specific, application-specific, machine-specific, environment-specific. Each should be found in a well-defined place/manner, and there should be a very-well-defined precedence among them (usually user over machine over application over environment). You will generally find that every configurable setting has a natural home in one location, but don't hard-code that dependency into your applications.

I find that it is VERY valuable to design applications to be able to report their configuration, and to verify it. In most cases, a missing or invalid configuration item should result in aborting the application. As much as possible, perform that verification (and abort) at startup = fail fast. Hard-code defaults only when they can reliably be used.

Abstract the configuration access so that most of the application has no idea where it comes from or how it is processed. I prefer to create Config classes that expose configurable settings as individual properties (strongly typed when relevant), then I "inject" them into application classes via IOC. Do not make all your application classes directly invoke the raw configuration framework of your chosen platform; abstraction is your friend.

In most enterprise-class (Fortune 500) organizations, no one sees the production (or even test) environment configurations except the admin team for that environment. Configuration files are never deployed in a release, they are hand-edited by the admin team. The relevant configuration files certainly never get checked into source control side-by-side with the code. The admin team may use source control, but it is their own private repository. Sarbanes-Oxley and similar regulations also tend to strictly forbid developers from having general access to (near-)production systems or any sensitive configuration data. Be mindful as you design your approach.

Enjoy.