process comments edit

We’ve all got our source code in source code control systems (right?) that get backed up on a regular basis (right?) so we can reasonably easily recover from any issues and get right back to coding. You might even have a backup program running on your development workstation so you can restore corrupted files or settings.

Are you backing up your continuous integration server?

“Why,” you might ask, “would I back that up? If I have all of my source in the backed-up source code control system, what else is there?”

It’s something I know I take for granted - the continuous integration build server just being there and working. But ask yourself some questions:

  • If you had to re-create your build server, how long would it take you?
  • If someone modifies your build configuration and messes it up, can you roll back the changes?
  • How easy is it to add or remove a project from your build configuration?
  • How easy is it to set up a brand new build server?

Sure, some of those don’t sound like disaster recovery issues, but by solving some of the issues, you can make your life easier on others.

Here are some tips that might help you make your continuous integration server experience a little more trouble-free. (We use CruiseControl.NET at Corillian, so I’ll use that in my examples.)

  • Check in your build server configuration. Store your build server configuration files (e.g., ccnet.config) in source code control, just like your product source. If you ever have to restore the configuration or roll back a bad change, this will make it vastly easier.
  • Isolate build artifacts from the rest of the server. Put everything that has to do with your build - your source, the build server configuration files, state information - in an isolated folder. If you can, put it on its own logical drive. This will help you in backing up, restoring, and moving to a new server (should you ever need to). You’ll know that all you need for the build server to run is in this one folder; everything else is peripheral.
  • Standardize everything. Your source code repository layout. The build output structure. The format of logs that get generated. Everything. This doesn’t sound like it’d be helpful in easing your continuous integration experience, but it is very helpful. By standardizing your source code repository layout across all the projects you build, it’s far easier to script any large changes to the build configuration. It also makes your configuration files look a lot like copy/paste work with minor substitutions. This ties into the next tip…
  • Generate your server configuration. If you have a standard repository layout, a standard build output structure, and so on, you’re only a step away from using a code generation tool to generate any server configuration you need. We have a small XML configuration file that has the differentiating bits for each project - the location of the source code repository, the name of the project, the version label prefix - and use CodeSmith to generate our ccnet.config file. We use that same XML configuration file and CodeSmith to generate a NAnt script that automatically adds any folders for the projects on the build server and do the initial source code checkout. Using Subversion as our source code provider and tagging after each successful build, we can even script re-creation of the CruiseControl.NET state file for each project. A keen side benefit of all this is that adding or removing a project on the server is as simple as updating the small XML configuration file and regenerating all the config.
  • Build on a virtual machine. If your build server is a virtual machine, you can easily take periodic snapshots of the system and restore the whole system to a previous state. It also allows you to start new build servers easier by cloning a good build server image and creating/generating the configuration for your new projects.

Check out your continuous integration setup. If the server died a horrible death in the middle of the night, how long would it take you to get running again?

General Ramblings comments edit

Everyone, I’d like to introduce Jack:

This is
Jack!

Jack is our new kitten, an eight-week-old Siamese/Tabby mix. You can see his body is light tan with white stripes, while his tail is dark brown with white stripes. It’s fairly subtle coloring on his body, but it’s really cool. He also has bright blue eyes like a Siamese.

Jack is a Siamese/Tabby mix - you can see the
stripes.

He’s wild - really wild - which is fun and will be good for our other cat once she warms up to him. She’s needed a playmate for some time. (Right now she’s being very territorial, but I don’t think she’ll be able to hold out for long - she just wants to be loved and you can tell she’s just jealous of the new baby.)

This little guy has more energy than I know what to do with, but once he’s played for a couple of hours straight, he crashes pretty hard.

Say goodnight,
Jack.

We name our cats after TV show characters we like, and this one is Jack for Jack Bauer (from 24) and Jack Bristow (from Alias). (Our other cat is Xev, from Lexx.)

Some folks post baby pictures, I post cat pictures. So there you have it - the new addition to the Illig clan!

General Ramblings comments edit

I was tagged by Scoble, so here’s my five things:

I was the valedictorian in high school. I’ve always been achievement-oriented, even before gamerpoints were invented, and school was no exception. While I let some of that perfectionism go in college, I was very academically competitive in high school. I can’t say it wasn’t rewarding - it got me a free ride through college.

I never wanted to be a programmer. This was on my “about” page for a while, so you might or might not know this. I originally wanted to be a 3D graphics modeler, not a programmer. Through some unfortunate misunderstandings on the part of guidance counsellors, I ended up getting a Computer Science degree. I’ve grown to like it since then, finding the art in problem solving. Plus, it pays the bills.

I’ve driven the DeLorean from Back to the Future. When I was young I went to Universal Studios with my family and one of the special effects demonstrations had the DeLorean from Back to the Future in it, showing how they made the effect of the car flying through the air. It was actually the one they used in filming, too. I got picked from the crowd to sit in the driver’s seat and “drive” the car while they green-screened in the flying effects. The flux capacitor was going behind me and all the gauges were running in the car, just like in the movie. It sounds dumb but I remember it like it was yesterday and still think it’s one of the coolest things I’ve ever done. I even have a small scale model of the DeLorean on my desk at work.

I won several spelling bees in grade school. I was huge into the spelling bee thing back in grade school, and did pretty well at it. Not good enough to make it to nationals or anything, but pretty darn good. I have a box of trophies in my attic to prove it. I even gave the spelling test to the class in fourth grade rather than having to take it myself.

I can’t stand newspaper or dryer sheets. Like, near phobia-level. I don’t like how newspaper leaves newsprint on your hands or the film that dryer sheets leave on your fingers when you touch them. When I lived alone, I never used dryer sheets; now that I’m with Jenn, if I find a dryer sheet stuck inside one of my shirts I make her pick it out. Thank goodness the stupid junk-mail paper that gets delivered to my house monthly comes in a plastic bag so I don’t have to touch it when dumping it in the recycle bin. I know this is going to prompt people to leave newspapers and dryer sheets all over wherever I go because people will think it’s funny and not actually take me seriously, but I really, truly, can’t deal with it.

There are probably actually like 100 things I could put on this list but most are either dumb or things you probably don’t want to know, so we’ll skip that. Instead, I’ll tag some folks I’d like to hear from: Aaron, John, Steve, Jason, and Wayne.

downloads, vs, build, net comments edit

New tasks added:

alpharesx: Alphabetize .resx files by resource ID.

lintrelativepaths: Fail the build if a reference hint path uses a relative path to a common location.

propertydelete: Don’t just set a property to an empty value - delete it so you can use property::exists to your advantage.

Go get it!