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

Say what you will about Microsoft, they know how to successfully build and release software. Vince Maraia has been a key member of the build teams for many of their major software releases over the last fifteen years. In this book he distills the wisdom he has learned about building software, while also setting it into the context of related steps, including configuration management and deployment. While he uses Microsoft tools and case studies from within Microsoft, the book is as tool-agnostic as possible, to make the ideas applicable to the broadest possible range of readers. The book is written so that each chapter builds upon the previous one, following the standard development schedule; however, each chapter can also stand alone as a reference to that particular piece of the process. Microsoft has been so successful at developing build procedures that work that they will be incorporating many of them in the forthcoming suite of products called Visual Studio 2005 Team System, so this book is being released at a very opportune time.

User review
Do Not Buy This Book
This book is simply awful. It offers virtually no useful advice, and is full of completely obvious recommendations. The only thing I gleaned from reading this book is that disabling virus protection on your build machines speeds up the build time.

User review
The Build Master
The book provides an excellent insight into the Microsoft organization's Software Configuration Management system. However, either the publisher or the author made many printing mistakes in the figures, letters were either left out or replaced with wrong letters in mass.
Other than the printing errors, the book is excellent.

User review
Several Microsoft ways that work and you can learn from
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.


User review
A very useful book
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.

User review
sketchy
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.