Saturday by chance at Borders I ran across the book The Build Master : Microsoft’s Software Configuration Management Best Practices by Vincent Maraia. Vince has been a member of the Microsoft build team for 5 years. Since this is the first book I’ve ever seen on this subject (not counting Pragmatic Project Automation, which is very Java specific), I decided to start leafing through it. After a bit, I decided to pick it up as it looked like it had some really interesting information that I would want to actually take home and go through in detail.

I guess the biggest thing that I have learned while reading this book is Microsoft platform based software is highly complex and that there is no real “nice” way to just buy a buiild system for the software. The other thing I learned is that Microsoft as a company actually takes this piece of the process serious enough that they fund a team to do it and I believe at one point Vince points out that the Microsoft build team is around 60 people. They recognize the cost savings that are possible in having a team managing this stuff rather than just letting the developers do what they need to do in order to get the software built – something quite refreshing to hear.

Vince goes through quite a bit of detail in how Microsoft manages their build systems, how they throttle checkins during release mode and have bugs move through multiple levels of approval before being allowed to be moved into the main source base.

One of the most interesting pieces of the book is where Vince explains the organization of authority around the build teams. Apparently, at Microsoft, the build team is actually the team that is responsible for rolling out new build tools and versions of the build process to the development teams and are expected to schedule and facilitate the release of new build processes after each software release. They schedule when new toolsets are migrated into the build environment, not the development team.

The build team also has complete control of their build machines – corporate IT does not. They have structured the ownership of the build labs so that they are completely in control of the build hardware, software and patches released to the machines and therefore are totally outside the corporate IT process for these machines. Vince talks about the importance of this structuring of authority and why it is necessary. Though when you read it it seems like one of those “duh” moments, its rare to find a book these days that actually supports and explains the reasoning behind machines needing to be outside the authority of corporate IT and why control needs to be given to the team for them.

Vince also goes through the new Microsoft Team tools and talks about some of their history and gives us a peek into whats coming up in future releases of these tools. The toolset looks really interesting and it seems as though Microsoft is actually taking the tools they have been using internally for years and productionizing them for release for others to use to manage the building of software in their environment. I guess time will tell as to whether these tools will be useful, but I liked the preview that Vince provides.

Some things I didn’t like about the book: Lots of focus on VSS, as apparently this tool is still used quite a bit at Microsoft. VSS has never been a valid revision control system to me and some of the techniques Vince talks about (like cloning trees and detaching them from the mainline for release branching) just struck me as inefficient. In my experience, as you fix bugs on a release branch, these changes have to be merged into the next release of the software (except in extreme cases where the next product is a completely different codebase like Windows XP vs. Windows 98) and this approach send you back to manual merge type of situations rather than merging between trees.

Overall though, this book is full of really great information. At the very least, you get a glimpse into the change management processes used in a very large company and an appreciation for the scale of a company like Microsoft and the problems they can have releasing software. You also get a good glimpse at the new tool sets coming from the Microsoft teams, which do sound quite interesting.

Just to give you an idea for the amount of information provided, take a look at this chapter breakdown of the book:

1. Defining a Build
2. Source Tree Configuration for Multiple Sites and Parallel (Multi-Version) Development Work
3. Daily, Not Nightly, Builds
4. The Build Lab and Personnel
5. Build Tools and Technology
6. SNAP Builds – aka Integration Build
7. The Build Environment
8. Versioning
9. Build Security
10. Building Managed Code
11. International Builds
12. Build Verification Tests and Smoke Tests
13. Building Setup
14. Ship It!
15. Customer Service Support
16. Managing Hotfixes and Service Packs
17. Suggestions Change Your Corporate or Group Culture
18. Future Build Tools from Microsoft

There are also four appendices: Embedded Builds, Extreme Programming (where Vince talks about Microsofts experiences in researching XP), Testing Guide, and Debug Symbols.

As an added bonus, the book is full of what Vince calls “Microsoft Sidenotes”, in which he uses real life situations at Microsoft to illustrate some of the points he is trying to make.

Overall, great book. There’s a lot of information to digest here. I’m definitely taking this one in and passing it around my team for review.