Most of the information out there on TFS Source Control is in the realm of software development, concerning the intricacies of branching, merging, build automation and all that good stuff.
But what if you want to use TFS to version configuration files? By that I mean the many artifacts that don’t get get compiled into an application but control how it behaves – I’m thinking of report definitions, data mappings, calculation logic and the like. As a broad definition, I call “configuration files” any sort of soft-coded business rules or settings. Configuration files might be edited in Visual Studio but also plain text editors, custom-built apps, or a vast range of third-party applications. XML is a typical format, but config files can be any plain text or binary structure (although the latter is thankfully less common). Often, the files are generated and modified by non-programmers: analysts, business people, subject-matter experts, and specialists in the particular technology being used.
Configuration files are no less critical than the application itself; in fact they can be much more valuable – representing many man-years of effort analysing complex business logic into a machine-friendly format. Such important assets need the rigour of version control, but how should that be set up? A good branching strategy is the right place to start for application code, but branching is not great for incremental releases – which are commonplace for config changes. Here’s why:
- Granularity: merging works at the changeset level and gets ugly if you attempt it at a finer level. Even though it’s possible, I also try to avoid merging specific changesets and instead merge only whole branches – otherwise it can get difficult to track what’s going on. Bill Heys has a great post on why you should avoid Cherry Pick Merges.
- Versioning: branching works for application code because it ensures integration and testing of a consistent whole. For config, you often need to identify individual files or small subsets which will be released independently. Branching doesn’t help there.
- Conflicts: there’s no branching without merging and that means the possibility of conflicts. Traditional line-based code lends itself nicely to standard merge tools but XML, proprietary text formats and (especially) binary don’t fare so well.
If branching is out for versioning config files, what approach should be taken instead? I’ve seen organisations manage the problem by recording changeset numbers or copying files to shares. Neither are particularly satisfactory, not least because of error-prone recording and the heinous crime of duplication. In the next part of this short series I’ll look at labelling as an approach.