Chapter 2. Source Tree Configuration for Multiple Sites and Parallel (Multi-Version) Development Work

Philosophy: There should be a single source tree that is owned by the Central Build Team and, if needed, that could be synced up, built, and deployed on any day of the year. This would be the mainline or "golden master" tree.

Vincent Maraia

If there was a way for me to patent this concept, I would.

This could be the most important topic in this book and the cornerstone of a successful software build process. I see customers struggle with too many cross-project dependencies, source tree integration problems, constant build breaks, and developers and testers spending too much time on hotfixes instead of writing new code. The majority of the time, these things can be traced to the way people have their source trees configured. Some development groups incorrectly blame their build problems on their version control tool's lack of branching functionality. By Microsoft's own admission, Visual SourceSafe (VSS) is not a very powerful Source Code Control (SCC) tool. (As discussed in Chapter 18, "Future Build Tools from Microsoft," Microsoft plans to change this with future releases of Visual Studio Team System [VSTS].) It's true that some of the tools out there are weak, but it is usually the source tree structure that is broken, not the lack of features or knowledge of these features.

Keep in mind that an SCC tool is simply just a database with a front-end application that manages all the items in the database. In our particular case, the application manages sources. In this chapter, we discuss the concepts of organizing your code. Then it is a matter of figuring out how to use an SCC tool to make it happen.

Many books have been written on setting up source trees and different branching models of version control systems such as Rational ClearCase, Merant PVCS, and Microsoft's own VSS. This chapter is about how to best set up your source trees and successfully track your code check-ins and your product, whether the application is a Web or a single platform application downloadable from the Internet or shipped out of the box. Also included in this chapter are the best practices that Microsoft has found in working with multiple development sites and using Virtual Build Labs (VBLs).

The VBL process was developed by Mark Lucovsky, a distinguished engineer at Microsoft who had a rich history at Digital Equipment Corporation (DEC) before coming to Microsoft in 1986 to work on NT (N10, or New Technology). The VBL model is an excellent one to use if you have multiple development sites or are trying to do parallel development on a product. This process is extremely good even if you have one central development location and one development team. However, if your product or company has a maximum of 10 or 12 developers and never plans to grow beyond that number, the VBL system might be overkill.

So, you ask, how does this topic on source tree configuration fit into a build book? Let's start with some basic definitions. Then I'll explain the connection.