Customer Reviews

The Build Master: Microsoft's Software Configuration Management Best Practices

5 star:		(4)
4 star:		(5)
3 star:		(2)
2 star:		(4)
1 star:		(1)

 

 

If you have a team of 30 or more programmers, then Maraia offers good suggestions on how to design your build processes so that these can both handle your current team, and scale up to hundreds or even thousands of programmers. The book uses Microsoft's own development effort as the central case study. Given that Microsoft has massive software development efforts, you may want to pay attention.

The book can be read at two levels. One is if you want to use the development tools from Microsoft, that the book talks about. If your team works under a Microsoft operating system, and uses Visual Studio, then indeed, this can be germane.

But you don't have to be using any Microsoft product at all, to reap some gain from the text. The key idea is to have a group of developers who maintain a centralised build process. (They can certainly have other duties.) Here, the book argues about having a metalevel, if you will. Where this build process can and will change over the project's lifetime. If the project has several subgroups, as it will if it is large enough, then each subgroup uses this same central build to make its own binaries.

The centralising fights a natural tendency for a large project to have subgroups that drift apart. In part by imposing a top-down discipline on the subgroups to have their developments conform to this build.

The book also goes into various good practices that your group should use. These have been covered in other books on software projects. The distinctive part of the text is the above discussion on the centralised build.

The author of this book, Vincent Maria, appears to have extensive knowledge of and experience with the build process at Microsoft. His knowledge if presented properly would be a very interesting and valuable book. Unfortunately, this book fails to deliver.

I was looking forward to reading this book, so maybe my expectations were high. I can't recommend this book - it lacks content. The book is a little over 200 hundred pages and has 18 chapters. If you factor out the introductions and graphics, you get about 8 or 9 pages of content per chapter. It would be very difficult to cover any of the chapter topics in detail in 9 pages. What you get is a very high level introduction to a topic with very little usable information.

Given the short length of the book, it would be more acceptable if the author were very concise. Unfortunately, I found his writing style to be redundant. Also, the book seems to be stretching for content. For example, there are actually 2 pages of email rules like "never open attachments from strangers", 1 page on why you should learn XML and of course, there is almost a whole chapter dedicated to how great the new Microsoft Team Foundation product is. I think about a quarter of this book could have been removed without losing anything.

Some of the recommendations in this book are childish and unprofessional. For example, one side note included tips for test managers to "Say 'no' to development at least once a day." and "If people really want you to do something, they'll ask at least twice." and "On a regular basis, complain that the project is off track..."

The book is not completely bad. It is just not detailed enough to be useful. If you are implementing a build process from scratch, you might get a good overview from this book, but I would argue you could get better information from the Internet. One good source would be white papers from the patterns and practices group at Microsoft. There are also some good sources on build automation in the extreme and agile programming texts. If you are looking for a good resource on branching, check out Software Configuration Management Practices by Berczuk.

** Let me follow up with one caveat. Although it is hard to tell from the book title and jacket, this book is targeted at managers. With that in mind this book may give a non-technical manager a good review of the build process. For technical managers, I don't think this book has enough detail.

If you're looking to critique your current build system or if you're about to scale from an ad-hoc build environment to a team of tens to hundreds of people, it would be good to pick up this book and get an understanding of one way that has been proven to scale. In addition, this book contains a lot of hard-earned knowledge about details of how to run a daily build and deal with any breaks that happen in them as well as how to specifically integrate some pieces of the Microsoft toolset in a way that will ensure that builds done on developer machines work the same as builds done in the build lab. You will come away from this book with a deep enough understanding to create a build lab and roll out a multi-site build environment.

People new to builds and who are enamored of continuous integration will also be interested in the chapter on SNAP. SNAP is an automated checkin system - rather than doing direct submissions to an SCC system, developers provide their change to SNAP, which does a full build/test verification to ensure that there are never build breaks. Why allow the main source code to contain breaks at all?

The one area this book could've improved was in the presentation of details. For example, it will be difficult for people outside of Microsoft to recreate a SNAP-like system given the high-level overview in the book. Also, the formatting of some of the textual files (like the XML files from ANT and MSBuild) wrapped excessively on the page, making it difficult to read.

Two caveats for honesty's sake: I was provided with a free copy of this book and met with Vincent when he was working on an early draft of this book. But speaking as the person who drove the creation of a unified build environment for Microsoft's Developer Division, this is the best presentation of the systems we use that is available outside of the company.

This is an enjoyable book but I cannot recommend it as a good book on CM/building. If you are getting 3 or more books on configuration management, build and release - then this might be one.

What does it contain? Very nice thoughts on the build process and a great amount of entertaining anecdotes from the build process of teams at MS. It offers advice on building and integrating when you have many teams/products, etc which is good. Like it says in the intro, it reads like a case story at times.

It is nicely written, a quick and easy read and all in all not bad.

It is not a guide, it is not encompassing in any way, and I dont think it claims to be in the intro. Nevertheless, I did have my expectations higher - I would have wanted more on codeline strategies and the like. (For this, I recommend Appleton/Berczuks SCM Patterns, which is excellent, and probably one of the most strictly useful CM books out there.)

So: More details, that is what is missing. More specific problems and solutions to different areas of the build and release process. The talk is interesting but for several chapters I kept waiting for Mr Maraia to roll up his sleeves, until I realized that it was not going to happen.

But again, not a bad book - if you are getting half a shelf of CM books, this serves up some useful knowledge. Just know that it is not extensive, nor deep. But oftentimes rare.

While many people bash Microsoft for what they consider the dubious quality of their software products, there is no question that they must have an efficient configuration management system. With so many designers, developers and testers working on any single product, it would be very easy for any software development project to descend into chaos. Since Microsoft does manage to push new products out the door on a regular basis, they have to do a great deal right in the area of configuration management.
This book describes the Microsoft experience and strategies they use in managing their product build, testing, customer support and service pack cycles. There is also a chapter on some ways to change the corporate culture and the final chapter describes future build tools that will be released by Microsoft.
A great deal of the Microsoft experience is certainly expected, believable and worthy of emulating. Whatever the size of your development teams, the best way to learn efficient and effective ways of configuration management is to study what the biggest teams do. If they can do it efficiently then by copying them, you can get that same efficiency and perhaps squeeze it a little tighter due to your reduced size.

I have been in the computer industry for over 30 years and found this book to be very interesting and informative! Vincent does a great job of defining a build and explains how computers work(all one's and zero's), what compilers(inherently dumb)do, and general computer info like debug symbols, international binaries, build verification tests, and everything else you need to know about shipping a product. I really liked his 'tongue-in-cheek' approach and all of the 'war stories'.
There are some things he could have left out like the section on e-mail rules but overall I found every chapter valuable to me and my organization. This book has now become mandatory reading for our company.
The book did leave me wanting a little more detail and information on some topics such as tools, but maybe Vincent will write a sequel with details on specific tools. Or I can go to the specific tool site and get details from them.
Overall I highly recommend this book to anyone wanting to learn about processes used at Microsoft that have been successful over the years.

Bob

Frequently building and testing the complete source code of a large project is a good idea - and The Build Master by Vincent Maraia gives the reader the inside scoop of how Microsoft accomplishes this. He clearly describes the best practices developed at Microsoft through trial and error relating to his central thesis: build frequently or continuously and test after each build. This is valuable information. What is missing from the book are the details and features of the software Microsoft uses to manage the process, and unfortunately, this is fairly critical information.

The book has 18 Chapters, but 14 of them make up the core of the material. Of these 14, 4 are about software tools and 1 is about a software tool nearly unique to Microsoft. Chapter 1 starts the book by defining just what Microsoft means by a build and Vincent steps through the issues and pitfalls related to his thesis of frequent builds through to chapter 14. Of these 14 very readable chapters, Chapter 2 is on source control software tools, Chapter 5 on build tools, Chapter 6 on a tool called SNAP used at Microsoft, and Chapter 13 on setup tools.

On SNAP, Vincent states, "I have seen similar tools at some customer sites, but none is fully automated or developed as well as the SNAP system." As a contractor on the team credited to development of SNAP, I will go further and say good luck implementing the continuous builds recommended without a tool like it. Fair disclosure: I was the key developer of SNAP, so I was there when the Netdocs team was trying to make it work. As a result, my perspective from the inside makes the book seems a little bit like a driver's instruction manual for a car when most readers only have bicycles. That doesn't mean the ideas are useless. My small development company of 10 people follows Vincent's advice verbatim and I can personally relate many experiences where these best practices made the difference between a successful and an unsuccessful project. But we use SNAP to do it.

This is a sorely needed book for anyone in the process of managing or introducing an automated build process into a development team. There is nothing ground-breaking here for experienced managers, however, it's a great reference book and covers all the major areas of concern regarding the build process. I've also found it to be a very useful resource to help build consensus in the team regarding the why the need for a build process and how to define it. This neatly fills a void in the book market.

Vincent works for Microsoft and has consequently had unique access their development organization. This books reflects this fact with frequent stories and asides - and for which alone its purchase is recommended. There is some good advice and tips in here, however I don't particularly like the latter chapters as they merely descend into an advert for the build capabilities in the (at the time forthcoming) Microsoft Team System.

The fact that the author has been working for Microsoft and that he managed to get a foreword written by Jeffrey Richter do a good marketing job, but the book is disappointing.

No issue is treated in detail, and instead too many obvious remarks are provided (such as "Test the product fully before shipping..." or "No hardware is allowed to enter or leave the build lab without a team member's okay").

The only valuable idea is the so called Virtual Build Lab, which is nothing more than a separate codeline for a sub-project, which is merged to the real mainline only when it is stable enough. This idea comes naturally in big sized projects.

Berczuk book on Software Configuration Management is by far a much better choice.