Last week, I finally got a chance to implement an automatic build process. It was actually quite simple. We used Cruise Control.NET as the continuous integration tool, and Nant as the building tool. Our source control tool is Visual Source Safe. It all fit together nicely, and I got it set up in about half a day.

So what does that give us? Anytime someone checks in a file in the current code branch, a build is kicked off, and I get an email telling me what happened. If it breaks, the team gets an email, and when it's fixed, they get another email. Each email details what changes were made, and who made them. I also am using cctray, a tool provided with Cruise Control.NET, so I have a tray icon that changes color when the build status changes.

I did have a couple of challenges though. The development is divided between our team and a team in California. The team in CA is building their own application and a shared component (a business layer). We are using that business layer, along with our own business layer. The shared one contains items we both need. Right now, we just reference a DLL, which we'll overwrite as we get a new one from CA. Is this the best way to do it? Each person pulling the solution out of VSS has problems, and have to set a path in their csproj.user file to point to their location of the DLL (it's a relative path, but our websites reference it, and VSS puts that in c:\inetpub\wwwroot by default - and the DLL is put where ever they decide to put it). Kind of a pain, and I wish there was a better way (no, it's not going in the GAC).

The other challenge was the build file for Nant. When you build a Nant build file, do you specify each file that should be built, or do you specify the folders to look at, and build all files in that folder? Both have limitations. The first one is reliable, but every time you add a file, you have to modify the build file. The second (with VSS) can be dangerous. If I add a file called cutsomers.cs, realize I can't spell, and add Customers.cs and delete cutsomers.cs, the project file knows that the file isn't part of the solution, but VSS still has the file. That means that getting the latest version, and building, you'll get a Cutsomers class in your DLL. Not good. Our eventual solution? Go with the <solution> task. It takes out both of the above issues, and it keeps things in synch with how the developers work with VS.NET.

Eventually, I want to get this implemented for Tourney Logic, which will be using CVS for version control by the time I get around to getting CC.NET working. Right now though, the focus is on the next version of the bracket control, not the build process.

Now, I just need to get one of these on my desk.