Introduction to Release Management with VSS

Introduction to "Release Management with VSS"

Microsoft VSS has many features that support the needs of software development teams building multiple, simultaneous, different versions of complex, multiproject software applications. Unfortunately, it is not easy to come to a quick understanding of the features or how to use them for sensible release management. This explanation is geared toward helping development teams understand better ways of using Visual SourceSafe 6.0 to manage project multiversion releases. Some specific techniques are suggested that align with other best practices published by Microsoft regarding software development.

Tools

Because this example uses VSS, and VSS offers numerous interfaces and utilities, the following is a partial list showing the most pertinent applications for techniques described in this chapter:

• VSS Explorer Graphical client application for interacting with VSS.

• SS.exe Command-line client application for interacting with VSS. This typically does everything that VSS Explorer does, but in some cases, it can do more.

• Analyze.exe Command-line application to maintain integrity of VSS databases.

• VSS Administrator Graphical client application to administer VSS users and databases.

Versioning

Having a clear concept of versioning is key to release management. We went over this in great detail in Chapter 8, "Versioning." This section focuses primarily on the "code" style (or file) of versioning because that's the basis of release versions.

Versioning in .NET Code

By convention, a version number for source files, executable files, projects, and solutions follows a common format:

Major.Minor.Build.Revision

Visual Studio .NET automatically builds this information into your source code using the AssemblyVersion attribute. By default, the version information it chooses is 1.0.*. You can use an asterisk in place of "revision" (or in place of "build.revision" ) to request Visual Studio .NET to pick a unique number (or pair) for each build. Following are best practices for individual developers to set the .NET assembly code version:

• Include specific numbers instead of the asterisk for default.

• Set Major.Minor to the release you're working on, and leave it there.

• Increment build once per day using automated scripts that build the entire solution each night.

• Increment revision throughout the day as necessary. For instance, developers who are creating COM objects, COM+ components, or modules that must be installed to the GAC to test should keep this number static as much as possible. Developers whose code is cached or has many dependencies might want to change this number each time they build. It's a good idea to use an asterisk for the revision number.

Versioning in Source Control

VSS has its own internal versioning system that uses sequential whole numbers only. It's useless to try to map these numbers to the dotted version number for software. To maintain alignment of software versioning in VSS, use the labeling feature. This technique is described later in this chapter.