|< Day Day Up >|| |
Automation is a lovely thing to have, but you may run into some problems when trying to automate your current manual build processes. Other issues will pop up when you try to share an automated solution with a team of developers. In this section, I’ll look at four common problems and suggest ways to solve them:
Tools that can’t be automated
Developers with different environments
Losing time over broken builds
Keeping versions up to date
You may also run into situations where a particular part of your process is difficult to automate. Earlier versions of RoboHelp, for example, did not expose any command-line interface or automation API. A manual built with these versions of RoboHelp was difficult to work into a build process no matter what tool you used. When you’re seriously committed to build automation, you’ll probably find yourself making sure that there’s some way other than a graphical user interface to drive any tool that you start using. But what can you do in the meantime?
For times when there’s no other solution, you can fall back on a user-interface automation program. Various applications are available that will let you record and play back mouse clicks and keystrokes so that you can automate processes that have no API. While such applications are inherently fragile (what if a window is in a different location than it was when you recorded the macro, or you forget and move the mouse while the macro is executing?), they can be the only workaround available at times. One free automation tool that I’ve used in the past with good results is AutoIt, which you can find at www.hiddensoft.com/AutoIt/. A commercial alternative with more power and a good track record is WinBatch (www.winbatch.com).
Developers are funny creatures. It may seem completely obvious to you that NUnit belongs in c:\nunit, but the person you’re collaborating with might have her copy in f:\utilities\bin\nunit. This can pose a problem if the two of you are trying to share a build script: the path to NUnit is going to be wrong for one of you.
There are two possible solutions to this dilemma. The first is to move all of the builds to a dedicated build machine, and to make that machine the one that matches the build script. This works well to make the build reliable, but doesn’t do much good if individual developers want to execute test builds on their own machine before checking changes in to the source code control system.
A better approach is to make use of environment variables. Just about every build tool can use environment variables in its work. For example, you might call NUnit from %NUnitPath%%\nunit-console.exe. Each developer can then set his or her own environment variables using the Control Panel System applet so that the script works with that individual’s particular arrangement of directories.
If your code base hasn’t yet settled down to something of high quality, you might lose a lot of developer time to broken builds. This can happen if you execute the daily build overnight, starting after everyone has left, but don’t look at the results until the next morning. This can leave you with a single developer trying to figure out the reason for a broken build while everyone else waits around with nothing to do.
If you’re in this predicament, the most productive thing to do is to make use of some of those hours between when the build is finished and when the team comes in the next morning. Your build tool can most likely send e-mail when the build is done, with a success or failure notice. Rent a pager with an e-mail gateway (which is common these days) and send the notices to the pager. Hand it to one of your developers each evening. If the pager goes off, that person gets to come in and get a head start on fixing things before the rest of the team.
Because this leads to someone working at 2:00 in the morning, you’ll need to be a bit creative to keep from being unfair. One alternative is to give the designated build-fixer the afternoon off. Another is to make the person who actually contributes bad code that breaks a build the designated build-fixer until someone else manages to mess things up.
VS .NET stores assembly version information in the AssemblyInfo.cs or AssemblyInfo.vb file. For example, in a C# program you’ll find this by default:
// You can specify all the values or you can // default the Revision and Build Numbers // by using the '*' as shown below: [assembly: AssemblyVersion("1.0.*")]
Unfortunately, this scheme of numbering is not very flexible. The build numbers that VS .NET selects will increase with each build, but they won’t follow any regular pattern. You can either put in version numbers by hand, or you can let VS .NET select them based on the time and date. Most developers would prefer to have some sort of auto-incrementing build number that goes up by a predictable amount with each build, or one that’s set according to a pattern that they specify.
If your build tool of choice doesn’t offer a way to force the version number, take a look at Matt Griffith’s UpdateVersion utility, available from http://code.mattgriffith.net/UpdateVersion/. This command-line utility lets you force the build number according to a variety of schemes, from using a fixed number to using calendar dates to auto-incrementing. I’ve used this utility from build tools several times, and it’s performed perfectly. In addition, Matt makes the source code available, so if you have a new numbering scheme in mind you can add it yourself.
|< Day Day Up >|| |