Philosophy: Technology and tools are useful and powerful when they are your servant and not your master.
Steven R. Covey, author, The Seven Habits of Highly Effective People
So many tools are available, free or at a cost, that it would be difficult to discuss all of them in this book, much less in a single chapter. Instead, I'll describe some tools that have been effective in my experience with builds and focus on two aspects of builds that are essential to automating your processes: scripting and binary generating (build) tools. When possible, I give links to the free tools or references of where you can download them.
Just like the earlier Covey quote, the approach in this chapter is that tools are just tools. I'd like to borrow another quote to make this point:
Don't blame your tools. A true craftsman doesn't blame his tools... the (tools) may be slow, buggy, or missing features, but the blame is ultimately yours. Blaming your tools is whimpy: Fundamentally, you either do a job or you don't.
Mac User Magazine
Rather than say "the blame is ultimately yours," I would rather say "the accountability is yours." The way I see accountability, at least the short definition is "So what? Now what?" Accountability has nothing to do with blame or fault, right or wrong. Rather, it has to do with who will own this going forward.
So if you are looking for that big, magic, miracle button to solve all your build problems and make your developers' lives easy, forget it. It does not exist. I have seen some really nice automation tools, but they are just tools that write or wrap your build needs with another script. I think having a bag of tricks is the best approach. The tools that I will talk about in this chapter should be the smoke and mirrors that you can pull out of that bag...the "big rocks" if you would like another Covey term. I'd also like to mention that the build process we will be talking about in this chapter is the Central Build Team's process that gets pushed out to the developers. This is the process that builds the complete product and is what the developers should use before they check their code in. (For a refresher, look at the section "Building from the Inside Out" in Chapter 1, "Defining a Build.")
Microsoft Sidenote: What Build Tools Does Microsoft Use?
This is the most common question I get from customers is, "What build tools does Microsoft use?" Microsoft does not have specific rules that every product development team has to follow. Instead, we have a lot of best practices or guidelines on what or how to run a product group. This is flexible by design. Some processes or tools might work for some groups but can be a real hindrance to others. The Windows team tends to be the de facto leader when it comes to the best build tools and processes. The other teams occasionally seek information about what works for them. The assumption is that when a process works for a group with more than 2,000 developers (Windows), it will scale down just as effectively. But because each product is rather unique, the questioning product team decides on what it can or will adopt to improve its processes. This is also the basis of this book: To throw everything we do at Microsoft "on the table" and let you decide what your company or group should adopt.
So, to answer the question, we currently use in-house developed tools but are progressing toward adopting the VSTS tools that will be available when Whidbey (Visual Studio 2005) ships. (Note: Some of the VSTS tools that will ship, such as prefast, are what we have been using internally for years.) I don't think we have statistics on what percentage of developers use Visual Studio for their code editor, but it has to be in the high 90s. You can't beat Visual Studio's intellisense and debugging! For the build in the various build labs, build.exe is popular, but MSBuild.exe is gaining some ground. Some groups use nmake and makefiles, whereas others have developed their own wrappers for devenv (the command-line tool for Visual Studio builds).