Yesterday I asked what build and release managers do. I’m going to keep asking questions, and answer them to the best of my ability as I go.
In Ship It! Jared Richardson and William Gwaltney have a chapter about scripting your build. You should be able to run a one line command that fully builds your product and that works on every developer’s machine. In the chapter, they discuss the importance of scripting your build from day one, as well as different tools for making that easier.
This is a great start, but what does it mean in real life? Real life is messy. If you’re a normal developer then you probably work on multiple products and there are interesting dependencies among those products. For example, it didn’t take long before my work on the Kiln installer led me to make fixes to the FogBugz installer (a dependency). Also, any given product is made up of many components, some of which are shared - used in other products. And a given developer may not be making changes to anything except shared components. I am sure you can come up with other interesting scenarios.
And the possibilities multiply even more when you start considering different configurations of your software. What if you need to build the 32bit version, rather than the 64bit version? Maybe you need to build a debug build to get better diagnostics, or a ship build because a bug only shows up there. Kiln and FogBugz also have licensed builds, that our customers install on their servers, as well as hosted builds, where we host the products on our servers. Each of these configurations is a different “build” that I’d want to be able to create using my build script.
What you really want is a standard way to script builds within your organization. Building any given component should take a one line command. Building any product should take a similar one line command. The easiest way to do this is to have a standard build system and script in each directory of your source code that can be built. So to build your custom ui framework, you could change to the directory where the code is and type build.bat or make or whatever. The script for a bigger product works the same way, but it builds the necessary components also.
Your build script should use command line parameters for building different configurations, with intelligent defaults. Here at Fog Creek, the default build.bat should create a licensed, debug, x64 install of FogBugz or Kiln on the developers box. But the build script should also take parameters that allow me to create a hosted, release, x32 installation of FogBugz.
All in one command.