Hanselminutes is a weekly 30-minute podcast with Web developer and technologist Scott Hanselman hosted by Carl Franklin. The following is a transcript from show number 4 on Continuous Integration. You can listen online at www.hanselminutes.com.

Carl Franklin: All right so let's get into Continuous Integration. Why don't you start by telling us what it is?

Scott Hanselman: So Continuous Integration is a concept that came from a paper that Martin Fowler wrote along with a guy named Matthew Foemmel from ThoughtWorks. Martin Fowler is the chief scientist at ThoughtWorks. And he uses the term Continuous Integration within the larger extreme programming or XP series of practices. Continuous Integration is something that's been around for a long time but people really never put a name on it. It's the automation of a daily build, the formalization of that process, keeping a single place where all the source code lives, so that everyone can always go to the exact same place to get the current source for the current (and any previous) version. It's automating the build but it's also automating the testing so that you can run the test on the entire suite at any time. An executable would pop out of the end.

So the ideal Continuous Integration environment, in my opinion and in many people's opinion, would be: A developer sits down. He checks out his code, goes out to the command line - he types, "build," and he gets a complete build that is totally tested on the spot. If he says something like "build install" it will actually pop out an MSI installer and he's completely set up. He can do this in a repeatable fashion on any machine. He can make changes to the code, check it in, and a build server dedicated to this task would automatically run the build upon his check-in.

Now, there are some arguments: that you do these things on a schedule, or you do it on a check-in. For us at Corillian we do a combination. Every single time someone checks in, a server on the other end starts watching, and says, "All right I am going to kick off a build. Someone just checked something in, I want to kick off a build, but I'll wait 10 minutes just in case there are other things coming." Because when you do a check-in you might have a couple of things batched up. So it's not going to kick off a build every single check-in. But once a batch of things has been checked in and nothing has happened for, say, 10 minutes, it says, "All right. Something dramatic has happened. I am going to run the build. I want to test the build. I'll build and install and I'll send the report to the entire team."

CF: How long typically does that process take for you guys?

SH: For us using a big project we have got one that takes as much as an hour but for a smaller project it can take between 10 and 20 minutes.

CF: And is it easy to interrupt? Let's say you actually did want to add something else and you knew that it was going to break.

SH: Yeah, that's a good point. If you check something in and you knew that it would break the build, if you didn't check it in within that first 10-minute window you are out of luck, you'll get a broken build. But the build would be fixed on your immediate next check-in. So we have literally dozens of builds a day.

CF: Interesting.

SH: So there are a number of tools that you can get, the most well-known is one called CruiseControl at cruisecontrol.sourceforge.net. There are also some competitors: Draco at draconet.sourceforge.net and Hippo, which is another old one that hasn't changed very recently (hipponet.sourceforge.net). But CruiseControl is largely thought of as being the one that is the most mature. It's the one that is managed by the ThoughtWorks guys. And this is an automated build solution and a server for .NET written in .NET. The final 1.0 release came out last November, although we have been using it since version 0.7.

CF: Very cool.

SH: CruiseControl runs as a Window service. You can also run it from the command line. It will watch your source control and check to see if anything is updated. It works with virtually any source control - CVS, SourceSafe, Perforce, SourceGear, PVCS, StarTeam; any source control that's out there that's worth its salt will work just great. When it detects that a change has occurred then it will kick off the build. Typically these builds are kicked off using something like NAnt, the .NET port of ANT, which basically make files with angle brackets.

CF: Yeah.

SH: You can get that at nant.sourceforge.net and NAnt is similar to MSbuild and there are already people on the Net who are using CruiseControl with MSbuild. So at its simplest you can certainly kick off a batch file. But for the most part CruiseControl and NAnt go hand-in-hand. The idea is that you should always be able to check your source out, go out to the command line and type 'build' or 'go' or whatever, and get a build, it needs to be that simple.

So when you're building these NAnt files you typically build targets within them. So you will say build all, build test, build install, so that people can hit these different targets: build debug, build release, these are all targets within the NAnt file, this XML-based file. These tasks in the NAnt file can be written by you or picked up from other places. So, there's a task for getting source from source control. There might be a task for calling a Web Service or looking in the registry. Each of these tasks is associated with a specific XML element in that NAnt file.

CF: That's great. How long have you guys been using this?

SH: We have been doing this for probably three-and-a-half or four years. This is one of the first things that I wanted to make happen when I got to Corillian. We also have a number of XP pundits. We had Wayne Allen, who is an XP expert. We had a guy named Jim Little and now Jim Shore who worked here at Corillian, and now works elsewhere focusing entirely on XP. So we really had a nice confluence where all these people who are into this style of development came together really quickly. And then Patrick Caldwell bought a thing called an Ambient Orb. This is basically a big crystal ball that would glow green or red depending on the health of the build.

CF: Oh gosh!

SH: Other people online have put together Budweiser neon signs that flash if the build is broken. The idea being that collective code ownership happens when you have an automated build.

CF: Yeah.

SH: If you schedule a build you don't know how things are doing. You don't know if you're healthy. But if you can look up and see a stoplight that says red, green, yellow...you know that things are good.

CF: So where does FxCop fit into the puzzle?

SH: So this is the thing that's so amazing about Continuous Integration and it's the simplest, it's simply using NAnt and NUnit to build and test your stuff. But what are other things you could do to really improve the quality of your software?

CF: Yeah.

SH: FxCop is a rules engine you can get at shrinkster.com/bmb. This is a tool that Microsoft released. It has rules like properties should have camel casing or make sure that public interfaces have words that are spelt correctly. I mean all the kinds of things that really go unsaid that you say should happen: don't put misspelled words in public properties or anything for that matter.

CF: Right.

SH: Or make sure that when you are doing COM Integration, you have COM visible equals true or false. I mean there's a litany of rules that the guys that made the Microsoft Base Class Library, the .NET BCL followed, and you get these rules as well. And then you can write these rules yourself.

So after you build, and after you test, FxCop can be run at the command line and generate a report that tells you all these different things about your source code. With FxCop it's all done via Reflection. And we've added rules, pluggable DLLs you can write yourself to check for specific things that you want to cover within your particular project: rules about how properties should be named, how fields should be done, how inheritance should work. It's totally up to you.

What's great about this is that the XML report that comes out of NAnt, the XML report that comes out of Nunit, and the XML report that comes out of FxCop are all brought together automatically by CCNet, the CruiseControl.NET (it's colloquially called CCNet), in what's called a Publisher. So you go into a file called ccnet.config and you can set up multiple publishers saying "Well, I've got some XML coming from here and some XML coming from here and I want to use these Style Sheets, these XXL Style Sheets, a lot of which come with CruiseControl to build up a giant report at the end." So I'm going to take that XML that comes out of each of these different tools and turn it into a really rich dynamic report that gets sent out to the entire team and they get told how things are doing.