Coder to Developer: Tools and Strategies for Delivering Your Software

There are many ways to tell whether a software project is in trouble, but here’s a three-question pop quiz on the subject:

1. Can you, right now, produce a fresh copy of the application and all of the surrounding artifacts (such as documentation or data files), starting from source code?

2. Can you reproduce the application and all of the surrounding artifacts as they were on this day last week?

3. Can you go get a cup of coffee while all this is happening automatically?

If the answer to any of these questions is “no,” then your build process could use some work.

The Big Picture

Just building your application is easy: Decide whether you want a debug or a release build, and then select Build Solution or Rebuild Solution from the Build menu in Visual Studio .NET (VS .NET).

But the simple approach is not sufficient for a project of any reasonable size. That’s because manually building just the code when you think about it doesn’t account for all of the other tasks that are involved in turning out the final package. If you’re working with other developers, for example, you need to remember to get the latest pieces from your source code control system before building. You might also have unit tests to run through, documentation to update, and so on.

The problem with attempting to put all the pieces together by hand is that people tend to forget things. When you’re trying to pull together a product, forgetting things can vary from being a nuisance (forgetting to run the unit tests before you check in code that breaks someone else’s work) to becoming a full-fledged disaster (shipping an old version of the help file to customers with the released product). That’s why you should be using an automated build tool for any project.

I’ll look at a number of build tools in this chapter, but they’re all designed to bring two main benefits to developers:

• Simplicity Instead of needing to remember a dozen or more separate steps to turn out a complete copy of your software, you launch the build tool and tell it to go to work.

• Reliability Because the steps to create a build are programmed into the tool, the build process never skips steps or forgets things.

But there’s more to using a build tool than just producing reliable builds easily. Once you have your build process under control, you can proceed to implement a daily build routine. Actually, it doesn’t so much matter whether your daily builds are done daily, twice a day, or once every two days. What’s important is that you have a regular schedule for building your software from scratch.

It seems obvious when you think about it, but in order to actually ship a product, you’re going to need a perfect build, where everything works just the way it’s supposed to: no errors in compilation, no failing tests, no missing files. The best way to get to the point of being able to produce such a perfect build is to produce a perfect build (or as close as you can get) every day. The ritual of building serves as a bit of clockwork for the project, a way to ensure that you’re constantly moving forward. It also affords you a quick check on the quality of your work: If the daily build fails to finish, something is seriously wrong.

Teams that build high-quality software take the daily build routine seriously indeed. On major Microsoft products, for example, “breaking the build” is such a serious issue that any developer who’s responsible is liable to be the one who has to stay late to fix things. While you may not want to make yourself stay late when you’re a team of one, implementing daily builds will still help you keep in mind that the goal is to ship software, not just to write code.

Tasks for Daily Builds

When you’re ready to choose a build tool and set up a build process, the first step is to figure out just what it is that you want to automate. Different projects will have different needs, but in general, the more you can do automatically the better. Here’s a selection of tasks I’ve done as part of daily builds on various projects:

• Get the entire source code tree from the source code control system to a clean directory. You should avoid doing an incremental get; the source code control system is your record of what you’re building, so you should always make sure that what you build from is exactly what is stored.

• Create a build number, date stamp, or other unique identifier for this build. VS .NET will generate random-looking build numbers automatically, but I prefer to impose my own numbering system. I’ll discuss this later in the chapter, in the “Managing Software Versions” section.

• Label the source code tree with today’s date or another identifier, to make it easy to verify in the future exactly which pieces are included in this build.

• Build the source code. This may involve multiple compilation steps if your product is split up into a variety of executable and library files. Here, again, you should do full builds rather than incremental builds. You might also want to build multiple versions of each file, such as debug and release versions, with different target folders.

• Run the unit tests for the project and verify that they pass. If running all of the unit tests would take too long to be feasible, it’s usual to design a set of targeted “smoke tests” to ensure that nothing too serious is wrong—the equivalent of plugging in a new appliance and watching to see whether smoke comes out of the case.

• Apply obfuscation, signing, or licensing tools to create the versions of the application that will be shipped to end users.

• Build the documentation and help files for the application.

• Build the installer for the application. I’ll talk more about installers in Chapter 15, “Delivering the Application.”

• Produce a report on exactly what was done and distribute it to interested parties. This might mean sending e-mail to members of your team, or automatically creating a daily XML file that can be displayed on a website with a suitable XSLT style sheet.

• Save an archived copy of all of the outputs from the daily build (including software, documentation, installer, reports, and anything else that’s not in the source code control system) as a Zip file in a known location.

• Distribute the finished products via e-mail, network share, FTP, or other means to interested team members.

Not all build tools can handle all of these tasks, of course. When you’re evaluating build tools, one thing to consider is how much of your process a particular tool can handle.