Word about task-driven configuration management

Recently I read an interesting post that attempts to explain how configuration management process has evolved from “file-based” into “task-based”; and am writing mine as some of the opinions expressed there are arguable.

First of all, the concept of task/feature/change request artifact associated with the changes to code is not new; first commercial CM system, CCC Harvest (dating from mid-70s) already employed this concept; and the current version of the software is still built around such artifacts. Thus the idea of configuration management process driven by the change artifacts rather than by the changes in code files is every bit as traditional.

Another misconception is that configuration management using files-based version control alone is simplistic as compared with task-driven CM. Branch/merge model, labels (snapshots etc.), concurrent check out and other concepts that are file-based provide for pretty flexible environment, and many of the tasks attributed to task-driven tools are achievable (as illustrated, for example, by Perforce). 

But it is certainly intriguing how nowadays for most CM tools the integration with meta-data artifacts other than files (however they are called - tasks, CRs, defects etc.) became one of the most important and requested features.

Personally, I have a theory that tasks-driven approach become more popular due to the changes in the way software development is done. While task-driven process was available for years, usually it was an integral part of a rigidly formal structure. The distance between defect filed by the customer support and developer who handled the bug was huge and involved multiple tiers, and smaller shops just did not have the resources required for such multi-tier formalized setup.

But in recent years, development become more and more “agile” (for the lack of better term), and the “path” between code and related artifacts become significantly shorter. And the process itself changed as well – perhaps that’s why the tools that worked well for enterprise in the past (CCC Harvest or IBM Rational ClearCase/ClearQuest) find it increasingly difficult to compete with less formal and more flexible competitors. Microsoft Team Foundation Server is a good example of the tool that can fit into enterprise environment but is still sufficiently agile to be a valid choice for less formal one.

There are some things in TFS that you can achieve by using work items in conjunction with source controlled files:

• Associate work items with checked in files (and enforce the association using check-in policy); that way every set of checked in files has bug, task, change request etc. aligned with it
• Establish what work items are contained in specific build (based on changesets contained, work item – changeset associations and build labels)

However, there are things that are not available (out of the box), for example

• Merge changed files from branch to branch based on work items
• Get file versions based on work items (f.e. get me versions associated with bug fixes X, Y and Z)
• Partition file revisions according to the work items state

Important as they are, the missing features hardly pose insurmountable obstacle in TFS adoption (of course, unless you hit some political snags along the way – you know, of the kind “if X is not supported exactly in the way I want it, we are not buying it”). If you believe otherwise, I would be very interested to hear about it.