Thursday, August 10, 2006


Automated Builds

Jim Shore posted a good article today about the pleasures of a automated build. By coincidence, I created an automated build script for our team's project today, so I have a lot of thoughts about it swirling around my head.

People not in the software business might wonder what a "build" is. Briefly, a software product is created by bringing together a whole lot of files (often thousands), and running them through a series of preprocessors, compilers, linkers, unit tests, and packaging tools. The process usually takes a long time and a lot of CPU cycles and hard drive space.

The process is particularly difficult when it involves a lot of manual steps. A typical manual build process might be something like the following:

  1. Build Master tells everybody that it is time to make a build, and asks everyone to get their code into the repository. Then Build Master waits an hour or so while all the other developers try to finish "just one more thing".
  2. Build Master opens source repository browser tool, navigates to the place where the code for a component is, then chooses the "Get Latest Version" command. Build Master then sits for five minutes while all the code is copied to the build machine.
  3. Build Master opens Integrated Development Environment (IDE), opens the project/solution/workspace/Makefile/whatever, and issues the "Build" command. Build Master then sits for five minutes while the component is compiled and linked.
  4. Build Master repeats steps 1-3 for each additional component that makes up the product.
  5. Build Master runs some simple tests to verify that all the components built and work together. This takes five minutes if the Build Master is lazy, or much longer if the Build Master is thorough.
  6. Build Master opens the packaging tool. Build Master modifies the package configuration to handle any new files and to update version information. Build Master then creates the installation package.
  7. Build Master tests the installation package, to verify that it actually will install a working system. Repeat steps 1-6 until this actually happens. (At this point, most of the other developers have gone home, so it will be up to the Build Master to fix any show-stopper bugs.)
  8. Build Master sends the installation package to the testers, then goes home. (By this time, it is long after 6:00 PM.)

The good thing about the manual way is that you have a person performing some quality control during each step, and the person can immediately start beating developers who have introduced defects. But it is very time consuming, and it is hard to reproduce the results of any particular build. It is much better to have an automated build script. Then the process goes like this:

  1. Build Master starts build.
  2. Time passes. During this time, the Build Master may work on other tasks.
  3. Build script completes. Build Master checks the build log for errors or anomalies.
  4. Build Master tests the installation package, to verify that it actually will install a working system. Repeat steps 1-4 if necessary.
  5. Build Master sends the installation package to the testers, then gets back to work.

Or the process can go like this:

  1. Everybody goes home at 6:00 PM, or whenever they finish their work for the day.
  2. At midnight, the build machine automatically starts up the build script.
  3. The following morning, the Build Master checks the results, then either sends a good build to the testers or starts fixing problems.

While automated scripts are clearly better, there is often reluctance to create them. Once they exist, people love them, but many programmers would rather spend their time mindlessly going through the steps then spend a little time automating the process.

Our team was like this. For the past six months or so, all the builds have been manual. The process generally took a couple of hours from start to finish. We talked many times about how great it would be if we had an automated script, but it just didn't get done.

Last week, I became Build Master. I decided I would go through the steps manually a few times to make sure I understood them. But today, I had a couple of spare hours, so I finally wrote that build script. It's a 25-line .BAT script.

It's not finished. Right now, it gets all the sources and other files out of the repository, builds the components, and puts them in a staging area. The testing and packaging is still a manual process, but I'll tackle those parts tomorrow.

If you don't have an automated build for your system, then make one. Trust me, it will make your life better.

Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?