How This Process Works: An Example Using VSS

The best way to show how a mainline owned by the build team works is by an example using VSS as the SCC tool. You can substitute any version control tool for this example. I chose VSS because it is from Microsoft, and it is free when you purchase Visual Studio Enterprise Edition.

Golden Tree (Mainline "Pristine" Build) Setup

Looking at Figure 2.1, you can see that the mainline or golden tree on the left is the shipping tree. This is the codeline that the build team owns, maintains, and administers. The goal of every development group and in this example Dev Team 1 is to get its code into the golden tree so that it can ship the product and get paid.

Figure 2.1. Golden tree.

The codeline called Dev Team 1 is considered Virtual Build Lab 1, or a sandbox or private tree. With the limited functionality of VSS, this is a new instance of a source tree, not a branch off the mainline. With more powerful source code control tools, this can be just a branch off the mainline.

VBLs and Multisite Development

Each VBL should be able to take a snapshot of the sources in the mainline (forward integration), work in isolation, and then submit its changes in bulk back into the mainline. This allows each VBL to work independently from one another while picking up the latest, greatest stable code from the other VBLs. As stated in the definitions, all VBLs operate independently of one another and choose when to refresh the code in their tree or branch and when to reverse integrate (RI) their changes to the mainline, making their changes visible to the other VBLs. The VBL work can be happening one floor or 1,000 miles away from the Central Build Lab.

Propagating the changes into the mainline is a big deal and is treated as such. This is the point where the Central Build Team sees the VBL's changes for the first time. Build breaks in the mainline are not acceptable and should never be tolerated. There should never be a reason for a break if the check-in policies for the mainline are followed. VBLs that are not able to produce reliable builds cannot propagate their changes into the mainline. Thus, their code does not make it into the product. This is good, tough logic, but it's the Achilles' heel of the VBL process. Although the threat of not shipping seems like it would be enough to keep the wheels rolling, it doesn't always work. There are too many dependencies between groups to say "Sorry, you will not make it in the product." That's why there should be aggressive proactive management of the VBLs through the Central Build Team to make sure the VBLs follow a stricter process. That way, they do not delay other components of the project because their build system is not up to par with the mainline.

Table 2.1 is a summary of the differences between private and public builds.

Table 2.1. Private Versus Public Builds

Private (VBL Build)	Public (Mainline Build)
Performed and managed by a VBL	Performed and managed by Central Build Team
Testing is minimal before releasing build	Minimum suite of tests must be run and passed before releasing
Can be done at any time	Usually done at a set time every day
Released informally	Released at proper release servers; ready for general consumption
Has its own rules and policies for check-in but should be dictated by the CBT	Strict, enforced procedure that must be followed for check-in
	Must go through WAR meeting to check in

When setting up a VBL structure, it is a good idea to keep the information in Table 2.1 in mind. It outlines the most important differences between VBL builds and mainline builds. If you decide to adopt this type of tree structure, I suggest that you elaborate on the entries in the table. The details will be dictated by how your development and test team is organized.

Performing parallel development after the VBLs are set up should be rather painless, a huge benefit of the VBL process. Each developer can branch in his own VBL to work on multiple projects while sharing the code across other VBLs through the mainline. Because the structure of parallel development and hotfix codelines is similar, look at the examples in Chapter 16 to get a better idea about setting up the trees.

What Should Be Kept Under Source Control

In some groups at Microsoft, we store only code or documents that need some kind of version control on them as they are being developed. Other groups use their SCC tool to store everything such as development tools, marketing work, and binaries. I am against the latter because I like to keep parts of the product separate. Despite what version control tool companies say, I do not think their tools are robust enough to track all binaries and other files that people like to store. Only code, documents, and anything else that needs to be built should be kept in an SCC tool. Third-party or external binaries, development tools such as compilers, and any other files that do not need to be built should be stored on a development server and kept up to date there. Release binaries belong on a release server. I discuss more about that in Chapter 3, "Daily, Not Nightly, Builds."