Are Change Packages Really Necessary in Software CM?
A change package in software configuration management goes by many names: update (my favorite), change, changeset, change package, changelist, patch, and others. It collects the files of a software change—a single logical update to the software typically created by a single developer. It may implement a new feature or fix a problem.
What Is an Update?
An update collects all files and other pertinent information for a software change into a single unit, which can be applied to the working build to produce an enhanced build. Can one apply the update to any build? No. The update itself requires a basic context—a product, a development stream or release, and perhaps an “iteration.”
An update must be able to capture the pertinent information about the change, including the following: files modified or created, approved reasons for the change (engineering change requests, problems, features, etc.) context (product, build, release, etc.), current state (open, checked-in, integrated, or tested), state history, peer review results, pre-requisite updates, description, compatibility (and resolution if necessary), directory changes (added and/or removed files and directories, directory splits, etc.), and "unit" tests (where "unit" is the update).
All of this gathered information is part of an update, and it is enough information for an integration into a build.
Is an SVN "commit" (see the tutorial: “Subversion Commits”) the same as an update? No. If you think to yourself, “Well sort-of, kind-of-a-bit, maybe,” I repeat: No. An SVN "commit" simply does not contain this information. Subversion “changelists” don’t really help either, as they specify lists of files only.
An update may implement all or part of a feature or problem fix. Or it may address multiple problems. Usually a problem is fixed in a single update but certainly not always. Often a feature is implemented across multiple Updates.
CM Professionals Know Updates Are for Real
An update is a real thing; it has a status and attributes. You can look at a delta report for a file, but it always makes more sense to look at one for the update. You can check in a file (i.e., a new revision of a file), or promote or merge it, but usually it makes more sense to do this with one update rather than with multiple updates with individual files. You can specify modification reasons for every modified file, but it’s better to specify these against the update and to associate each file revision with the update that created it.
In the late 1990s, recognizing the industry’s need for change package management, Rational introduced unified change management UCM into its software CM offering.
Updates are indivisible (atomic) units. SVN supports atomic commits, but this is quite different from the atomicity of an update that spans all of time. Neuma's CM+, for example, has atomic commits (i.e., transactions) to the repository, like SVN, but the update is distinct. Modifications to the update can span time and multiple transactions.
The CM industry realizes that the change package concept is fundamental to software CM. Life without updates is complex. A build manager wants to deal with twenty updates each night, not 153 files.
Some tools have updates nicely integrated into a CM and ALM solution. Others have them as an add-on, which is still preferable to a file-based CM capability that doesn't understand change packages. Many tools try a partial “task-based CM” solution, which, though better, still falls short. Read the white paper Change Package-Based vs Task-Based Change Control to see why.
If you're looking at implementing software CM, change packaging is your number one requirement. For a more extensive discussion of the matter, I recommend my article, CM: The Next Generation of Change Control.
