In the course of developing and maintaining software, teams will typically create or modify a large number of objects like source code, images, documents and binaries. A project might include hundreds of changes a day to produce a final release. Unfortunately a single mistake in a change to a line of code can bring down the whole system, making change tracking and control critical to software development.
A large internet consulting company recently realized that these issues were causing major loss of revenue for their organisation: their builds were frequently unstable because of missing files, incomplete changes and conflicting modifications, which limited the speed at which they could deliver new applications.
This stopped them from innovating as much as they needed to, stunting the growth of the company. What they needed was a solution that guaranteed change set consistency without creating extra work for the developers, to increase build quality and control.
Task-based configuration management (CM) provided this capability, allowing them to divide by 10 the amount of resources dedicated to unproductive efforts, such as fixing broken builds, and leading to an increase in development productivity of over 18 per cent.
Task-based CM is a best practice that increases developer productivity by automating the error-prone activities of traditional CM, enables project managers to control their builds and provides a competitive edge by improving team communication and collaboration.
An introduction to CM
Traditional CM tracks changes made to individual objects, answering questions such as 'What was changed?', 'Who changed it?' and 'When was the change made?' In order to provide better visibility and control over the system, CM also needs to answer these additional questions: 'Why was this file changed?', 'What other files were modified as part of this change?', 'What change request or defect does this change resolve?' and 'Is this group of changes in the latest baseline, and is it ready for test?'
Before looking at how CM might address the second set of questions, let's see how it addresses the first - who, what and when.
File-based CM
CM that addresses who, what and when typically uses a traditional, file-based approach that involves developers. They receive work assignments via email, telephone etc.; they then check out and modify files or create new files; they must keep track of which files were modified and added; they enter comments on why the files were modified or created; they must then check in all modified and created files, filling in label information and similar attributes; finally, they report what was done, to which objects and why.
In today's development environments, where a single change will often impact many files, this approach breaks down: a file-based CM system does not associate the related files, except perhaps by some free-form comment. These interdependencies must be managed manually.
For instance, a 10-developer team, each changing 10 files a day, will produce 500 changed objects a week, with possibly multiple versions of the same object. Manually trying to keep track of which files go together to provide consistent change sets is errorprone. Any omission or mistake will lead to an incomplete or incompatible set of changes when the changes are pulled together to create a build configuration.
If we had an 'Add CANCEL button to the OPEN MODULE dialog box' assignment, including the picture of the new dialog box, it wouldn't make much sense if we didn't include the source code that was executed when the button was pressed. If we omitted the button press code, the build might fail, the testing process might uncover errors late in the life cycle, or they might go undetected until after delivery to the customer.
Any manual process is errorprone, and the list of potential issues with file-based CM includes build problems, unexpected behaviour uncovered late in the life cycle, undocumented changes, unresolved dependencies or reduced traceability. Additional challenges include managing parallel development, merging code and backing out a destabilizing change. These numerous points of failure can dramatically increase cost due of a software project.
Task-based CM
Traditional, file-based CM doesn't answer questions like 'Why?', 'What else?', 'What does this resolve?' and 'Is this ready for test?' To do this, CM tools use the familiar concept of tasks, sometimes called 'activities' or 'change sets', to aggregate separate but related changes. For example, individual but related changes might be aggregated under the title 'Add CANCEL button to the OPEN MODULE dialog box'.
This title is also likely to be the name of the assignment from the manager as well as the level of information sought by the testing team. Developers working with an automated, 'task-based' approach:
- select a task from a to-do list;
- check out and modify files or create new files;
- complete the task.
The CM solution can then automate task-object relationship maintenance, commenting, object attribution and object check-in.
With a task-based approach developers can operate in terms of logical changes rather than individual file versions.While they still edit files, the modifications are grouped into a logical change set. For example, rather than having to remember the five files that were changed in order to complete the 'Add CANCEL button to the OPEN MODULE dialog box' assignment, the developer can simply check the task details.
Task-based CM avoids file-based CM issues such as developers forgetting to check in all files related to a change, the lack of a relationship between requested changes and modified files, and the manual management of change dependencies.
By assembling individual but related changes as tasks, task-based CM offers a level of abstraction that automates the developer's CM-related activities, provides project and configuration managers with powerful functionality for controlling the content of their builds, and greatly improves team communication and collaboration.
Tasks and change requests
Nearly all development projects need to manage change requests like defect reports, enhancement requests, requirement implementation requests and bug fixes. These change requests traditionally go through a specific process for review, analysis and implementation. They should be managed in a central repository and, ideally, in the same repository as CM for complete consistency and traceability.
Change requests are often implemented by a group of team members - component experts, domain specialists, software and hardware developers and documentation teams. A single change request may include several tasks and is implemented once all its tasks have been completed - a status impossible to determine if objects are directly linked to change requests.
Suppose we have a change request of 'When opening module, user cannot exit current operation'. This change request might be implemented with the following tasks: 'Add CANCEL button to the OPEN MODULE dialog box', 'Link ESCAPE KEY to cancel OPEN MODULE dialog box' and 'Update USER GUIDE to show CANCEL button in OPEN MODULE dialog box'. Of course, each of these individual tasks is linked to specific objects.
Tasks are both the natural concept for grouping object changes and also the intuitive work breakdown of a change request.
The benefits of task-based CM
A task-based CM process quickly provides benefits for all team members.
Increased developer productivity
Developers are provided with a to-do list of assignments, priorities and deadlines. The CM tool automatically tracks modified objects and handles 'check-in' and similar operations. Task-based CM improves documentation and traceability and verifying changes as part of a pair programming or code review process is easier.
Empowered project managers and improved quality
Project managers can view real-time project status reports and receive automatic notifications. Teams can define a software configuration as a previous release/baseline plus a set of tasks, enhancements or fixes.
As tasks move through the workflow, a configuration always contains the full change. Projects can start testing earlier in the development cycle because configurations are consistent at all stages; they can also build on-demand configurations and releases, allowing for project variants and parallel releases.
Project leaders can decide to remove or exclude a task from a build. A project manager can ask a developer to fix or rework a task just by creating a 'fix task'.
Enhanced project team communication and collaboration
Tasks are stored in the CM repository, establishing a knowledge base for future use. Task-based CM automates the identification of which tasks and change requests are included in a given software build or release.
The abstraction of tasks is understood by the rest of the team, leading to more effective communication. In addition, a task can represent an activity by teams other than software development.
Summary
Task-based CM provides a competitive edge in systems and software development by increasing developer productivity, equipping project managers with control over the content of their builds, and improving team communication and collaboration. With task-based CM, the goal of simplifying CM and improving the overall development process is achieved.
