Chapter 13. Building Setup

< Day Day Up >

Chapter 13. Building Setup Philosophy: No more rewards for predicting rain, only for building arks. �Lou Gerstner, Former IBM CEO You might be thinking, "What does setup have to do with building software?" A lot. I never set out to be a setup expert, but somehow I found myself researching and answering questions about setup even though my work was in build labs and on build processes. What seems to happen, as with most of the topics in this book, is that the build team by default becomes the owner of setup because it is the next step after the build is complete. When a team grows, a setup or install team is formed eventually. It is the build team's responsibility to create the setup packages and thus the build should not be released until setup has been created successfully. In the past, I used to recommend keeping build and setup scripts separate. For example, after all build scripts have run and some basic build verification tests have passed (such as a file copy script to ensure zero errors), we enter the post build phase or process. At this point, we build all the setup packages and deploy the product to test servers. Now my recommendation has changed to integrating setup into the build process and pushing the responsibility of setup back to the developers that own the code or modules that are included in a setup package. How can you do this? By using the WiX tool (which I talk about in this chapter). Performing the setup creation process on a daily basis is as important as building your product every day. The same reasons apply, with the emphasis on being able to build setup successfully�you do not want to wait until your product is about to ship to test or create setup packages. This would be like not doing any homework during a school semester and then attempting to do all of it during the last week of the semester, just prior to taking the final exam. Usually with the same bad result. This chapter covers some basic architecture of how you should design your setup programs using the Windows Installer XML (WiX�pronounced wicks). It provides enough information to give you a basic foundation on which you can build. This chapter is not intended to provide details about any specific tool. For specifics, search the Internet. A lot of good information is available for free. See the sidenote for download locations. Included in this chapter is some input from the WiX creator, Rob Mensching, and setup development lead, Christopher Hilbert, who also provided the example. Microsoft Sidenote: Wise, InstallShield, or WiX? Many customers ask me what setup programs Microsoft uses. Similar to build tools, no one standard is required, just some recommendations. In fact, we do not have site licenses for the two most common setup application tools: Wise Solutions (www.wise.com) and InstallShield (www.installshield.com). Microsoft leaves it up to the specific product group to purchase licensing agreements with whichever tool it chooses to use. Over the past few years, most groups have adopted a new choice: Windows Installer XML (WiX�http://sourceforge.net/projects/wix). WiX has been spreading like wildfire at Microsoft for the following reasons: Rather than describe the steps of installation in GUI form, WiX uses a declarative form that specifies the state of the target machine after various phases of installation. The WiX tool is designed to integrate setup development with application development, thus pushing the setup process back to the developers, who best understand the requirements for their components to install. It's free. WiX is the first project from Microsoft to be released under an OSS-approved license, namely the Common Public License, which means it is open source.

< Day Day Up >