Re: Handling non-git config files

[Jon Seymour <jon.seymour@gmail.com>]

[ Richard sent his own copy ]

I have used git in a deployment scenario and found it to be very useful.

The way I dealt with this problem was to treat the variants as a build
problem. During the build, I create a version of the deployment
artifacts that reflect a generic, uncustomized server. This gets
checked into a branch. To build the an environment specific variant, I
checkout the build result for the uncustomized server on a new branch,
customize it and commit that to the tip of the environment specfic
branch. The process continues down the hierarchy, so I take the
environment specific variant, customize it for particular servers and
commit that to a new branch. Each branch is represented in git as a
merge of the current build with the results of the previous build for
the previous for the same branch. [ Thereby allowing FF merges during
deployment ]

The end result is that I have a git repo with one branch for the
abstract server, one for each environment (all uncustomized or
partially customized) and one full customized branch for each physical
server. The whole repo can then be pushed to all environments (but not
checkout there). Deployment is then simply a question of pulling (or
checking out) the right tag of the right branch on each server at the
right time (e.g. after testing, during change windows etc).

Pulling has the advantage of preserving adhoc configuration changes in
deployed environments that have not been folded back into the build
process, though at some risk of merge conflicts &/or inconsistency. My
approach in the case of merge conflicts was to report the problem,
save the current state (in the git history) and resolve in favour of
the build product. Alternative strategies might be to abort the
deployment until the conflict is resolved, etc.

(I also used a separate aggregation technique to aggregate several
distinct repo into a single hub repo so that as to minimise the number
of git operations required to sync two nodes in the deployment
topology.)

Using git in this way was great - deployment of an incremental release
was super quick because the repos could be pre-deployed and transfers
typically only included files that had changed for the release - gone
are the big tar balls being transferred that contain mostly unchanged
stuff.