How This Book Is Organized


Each chapter can stand alone, but the book flows from software development processes to product support (sustained engineering). This is my idea of componentizing the build process and this book. You will get a better understanding of how all these topics are linked if you read this book from cover to cover, but I realize that some groups or companies will not need to spend a lot of time on a certain subject that they feel they have already mastered or are not interested in. If someone just wants help on setting up a build lab, he can turn to Chapter 4, "The Build Lab and Personnel," and get the information he needs without having to read the previous chapters.

Contents at a Glance

  • Source Code Control The "Golden" Rule

    Because it seems that the build team members tend to live in the source code trees and are usually the administrators of the trees, I spend a chapter talking about the best way to configure your sources.

  • The Build Process The Mission-Critical Assembly Line

    This is the cornerstone of this book. Nine chapters cover, in detail, how to build your product. For a more in-depth overview, please read the book's Introduction.

  • Setup/Release Ship It!

    This is another area that tends to spill over to the build team's responsibilities. This topic is covered in three chapters.

  • Sustained Engineering The Only Sure Things in Life Are Death, Taxes, and Bugs

    This tends to be the first area where symptoms of a failing project start to show up. Most notably, everyone on the project team is in reactive mode instead of working on new features.

  • The Future How to Get There from Here

    If you are interested in the new tools that Microsoft will be releasing with the future release of Visual Studio, I touch on how to utilize those tools using the processes described in this book.

The Story

As I write this, Microsoft is productizing some of its internal development-cycle tools to make them available to all developers via its Visual Studio Team System product. The production of this book could not have come at a better time because I can now explain how these tools and processes have evolved in addition to the best practices of product teams that drive the functions of these new tools. This is another objective of this book.

I recently completed a build architecture review for a large Microsoft customer. This customer already had a good build process and didn't think it needed much improvement. At the end of my onsite, week-long engagement at the customer's development headquarters, I suggested that this customer adopt the principles that I explain in more detail in this book. He agreed with me on most points but surprised me when he said, "I really appreciate all the information and suggestions that you provided. In order for you to have come up with all of these recommendations, you must have suffered through a lot of pain in the past." This statement blew me away. I never really viewed all of this experience working on builds at Microsoft for the past 15 years as painful, but just lessons we learned by "try and try again until we get it right."

Although some initial investment in resources will be required to reboot your processes if you decide to implement all the processes and suggestions in this book, you will save 3 to 5 years of the "pain" of learning all of this from the school of hard knocks. At the very least, you will be enlightened on how software is shipped at Microsoft. And as I always ask my customers, if you know of any other better processes than what I prescribe, please let me know. I am always open to improvement and would love to hear your suggestions.



The Build Master(c) Microsoft's Software Configuration Management Best Practices
The Build Master: Microsofts Software Configuration Management Best Practices
ISBN: 0321332059
EAN: 2147483647
Year: 2006
Pages: 186

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net