“Dad,” asked a young man, “my lady friends keep talking to me about being ‘involved with’ them versus being ‘committed to’ them. What exactly is the difference between involvement and commitment?”
“What did you have for breakfast, son?” his father replied.
“Bacon and eggs like always. Why do you ask?” said the son.
“Bacon and eggs, my boy, is a perfect illustration of the difference between involvement and commitment: the chicken was involved, but the pig was committed!”
The Task-Level Commit (TLC) pattern is used to bring the concept of a “change set” to the check-in process. Essentially, TLC is used to group a set of related changes to separate objects into a single task level operation. This provides a much more intuitive delivery model for code changes, and reduces various kinds of configuration and dependency errors. If your tool does not provide support for change sets, or something like them, you can still implement the TLC pattern using scripts.
Note that there are commercial products that provide this support, although the naming may be different. Aside from ‘task’, you may hear the terms ‘change set’ or ‘change package.’ There are differences in the various nuances of these terms, but for our purpose the differences are insignificant: either you have this capability built in, or you don’t.
This article assumes you can figure out how to perform basic TLC in your tool, and discusses what you can build on top of that foundation: task based development.
Task Based Development
The best use of TLC is in a fully task-based development cycle. In this model, all changes use the TLC approach, so there is always a task identifier for each change. An attempt to mix TLC with regular file-based development will degenerate into a chaotic muddle due to the inconsistent availability of data.
Tasks are natural elements for change tracking. It is important to distinguish between “change set” tasks and “project management” tasks. Generally, your project manager has tasks on her project plan with much less granularity than the coding tasks. CM and project management products are different, and so they use the same word differently. Explain this to developers and managers alike – there are always a few “managing” tasks that coincide perfectly with “coding” tasks, so you may have to search for a counter-example.
Tasks collect file changes
The basic ‘Task Philosophy’ is that tasks group together changes to files and directories. Instead of dealing with checkin and checkout on a file-by-file basis, TLC supposes that all of the changes are delivered as part of a single larger unit, the task.
This means that if 20 files are being changed, none of them should be checked in until all 20 are checked in. The corollary to this is that you shouldn’t change 20 files together unless they need to change as a group.
Tasks should be fine grained
Because of the coupling among all the files of the task, TLC is generally implemented using very fine-grained tasks. Tasks are NOT a surrogate for change requests – they should be short, simple steps, each of which can be confirmed to work. In this regard, TLC is well suited for use with an agile development cycle. The rapid turnover of agile project development matches the rapid cycle of task based development.
One keyboard, one task
One additional note about allocating tasks: each task should be accomplished by a single developer. Specifically, if more than one developer is needed to perform some work, create multiple tasks.
When a certain level of confidence is achieved, all the files associated with a task can be promoted. You can see that task based work tends to foster an ‘all or nothing’ approach: once you start managing with tasks, you want to manage everything with tasks.
The final factor to consider when implementing a task based approach to software change is the promotion model. When code is checked in as individual files, there is generally a test run to confirm the function of the individual file. Likewise, when TLC is used all