Release Management: General Scenarios

The following scenarios describe the chief approaches that generalized software development projects must use to maintain different versions of source code to support ongoing releases. The instructions are keyed to applications that are released to customers in multiple versions. These techniques easily scale down to accommodate single-deployment/same release.

Primary Releases

We will consider major and minor releases in this section as our primary release scenarios. Figure 16.1 shows a plan for using version numbers and VSS features to manage these kinds of releases.

Figure 16.1. Branch setup 1.

There is some controversy about how to manage the creation of new releases and what techniques you should use to mark and isolate code between releases. We'll examine four approaches and make suggestions for when to use each one: share and pin, branch, label, and clone.

Share and Pin

To create a new release, perform the share operation on a project folder to create a new project. In this new project folder, pin all the files to prevent them from being changed. Whenever you must change a file for the new release, either unpin it or branch it.

Unpinning a file automatically propagates changes between releases, because the files are shared again. This is usually not recommended. It can easily break the current release due to changed dependencies because the earlier version was created or the programmer is in an intermediate development state while trying to fix the bug.

Branching a pinned file automatically unpins it, but it also unties changes to its shared file. To propagate changes between branched releases, use the merge operation. This might break the current release, but it will probably make it more manageable because all merging is done after the change is completed and tested.

Branch

Branching is a great way to isolate changes from one version of the application to the next. An entire project can be branched. This is conceptually the simplest approach. It provides a clean slate for each release.

Too much branching has negative side effects, however. Because histories of a file go back through all the branches to the creation point, excessive branches can make the database too complex. In some cases, database corruption might result from rapid changes to many branches from numerous people. To a large extent, you can mitigate this with good administration, such as backups, but excessive branching makes that difficult.

Therefore, you should take advantage of branching's powerful benefits but limit its use to the most appropriate situations. Follow these two general guidelines:

• Only branch when you intend to merge at some point. It is good to follow this rule in most cases, but sometimes you will want to branch even though no merge is anticipated.

• Only branch the files you need to change, not the whole project.

Label

Labeling is a powerful feature that allows software developers to mark the latest version of every file in a project folder with a custom label so that those specific versions can be referenced by other operations, such as get, share, pin, branch, and rollback. You have the option of labeling a historical version instead of the most recent one.

Many people who have used the label feature of VSS use it for "big" builds, such as releases. But you can also use it on daily builds. This makes it easier to identify which file versions are affected by bug fixes and rollbacks.

The best practice for performing daily builds is described in the MSDN article, "Team Development with Visual Studio .NET," and implemented by the BuildIt utility described in the appendix to that article.

Clone

Clone is not a feature of VSS. It is a technique for copying a project when it is anticipated that the new project will not participate in merges with the original copy, such as is generally true for major product releases.

To clone a project, copy the latest version of the project into a new working directory. Then create a new VSS project from those files.

The two major benefits of cloning are as follows:

• A cloned project is disassociated from the original project, so there is no explosion of branching complexity.

• You can back up and restore a cloned project (including to other VSS databases) separately from the original project.

  Cloning also has drawbacks:

• A cloned project's history does not go back beyond the cloning operation (as it does for branching).

• A cloned project cannot participate in a merge operation with its original source.

Patch Releases (Service Packs)

Implementing and releasing patches is complicated by the fact that the patch has to apply to some past version of the application. Even if only one version is deployed, which is common in enterprises, it will be the most recently released version, and there will probably have been changes to the code base since then that are not ready for release. Figure 16.2 shows a plan for incorporating patch builds into the primary release scenarios to accommodate management of code changes affected by the patch.

Figure 16.2. Branch setup 2.

Because patches represent fixes against a specific release, it is logical to continue making changes to that release using the same technique that you used for primary releases.

Merge

When you create a patch for a previous version, it's good to apply those changes to other versions. You can use the merge feature to combine two branched files. This works by applying changes from one branch to another, leaving the "from" branch unchanged, so it's ideal for this scenario. You can merge branched projects using the VSS command-line SS.exe.

You can apply the Merge operation only to branched files, not to cloned files. In the case of cloning, which is recommended for new major releases, you have to apply changes that you would like to merge in a manual fashion.

Here are some points to keep in mind when merging with VSS:

• You can use VSS Explorer to merge branched files. To merge branched projects, use the VSS command-line tool. See article 142157 in the Microsoft Knowledge Base (http://support.microsoft.com/?id=142157) for more information, including specific instructions for using the command-line tool.

• You can only merge branched text files, not binary files.

• You cannot automatically merge cloned projects with their original source.

Other Approaches

Some authors believe in creating a separate project for each patch by sharing and pinning, or by branching. This specific example recommends labeling instead because that imposes less complexity on the database's internal representations of files. In this way, you help to minimize branching.

Parallel Releases

In this scenario, the code base is split so that ongoing releases of different "editions" of the application can be targeted to specific sets of users or markets. Figure 16.3 shows that a parallel release is not much different from a primary release.

Figure 16.3. Parallel release scenario.

The main differences show up later, when you must incorporate feature enhancements and patches from the primary release into the parallel release. You'll follow the same guidelines as for minor and major releases. In general, if a parallel release is considered a new minor release, use share and pin with branching. If a parallel release is considered a new major release, clone it. Also consider whether you anticipate merging it later.

Patching parallel releases works the same way as was described for primary releases. The more release versions you have to patch, the more merging you need to do.