TeamCity – A new tool for builds and continuous integration
One of the things I am currently working on is getting all of my client’s systems running with continuous integration. Back in the old days, when dinosaurs roamed the cubicle farms, that meant installing a lot of third-party tools and writing several hand-written scripts. With Visual Studio 2005, the solution file becomes a build file and there are some nice tools out there to help automate the setup of a CI server.
For those of you who may not know what continuous integration is, it’s a common practice used in agile development shops. Whenever a developer checks changes into the source code repository, a program starts pulling the latest version of the source down to a build server. The project is compiled, and the unit tests are run against all the code, to see if the changes broke any existing functionality. Some teams also add other steps in the process, such as running code quality tools like NCover , FxCop, and NDepend. Once all this is done (which should only take a few minutes), notification is sent out to let everyone know if the build is still good, or if something broke. I’ve used e-mails, web pages, and system tray tools for status updates. Some teams get lava lamps, sirens, or stop lights to make it very obvious if the build is good or bad.
I was starting to look at CI Factory, which helps you configure your build server and install all the other tools you need. However, someone showed me a cool new tool called TeamCity . It’s from JetBrains, the same people who write ReSharper. Their professional version is free, and so far, I’m really liking it. It has a very simple install and is extremely user-friendly. Instead of writing XML configuration files for CruiseControl, I just set the build type to ‘Solution 2005′ and point it to the solution file. A few other simple settings screens and I’ve got continuous integration running. It also has the ability to run build scripts for Ant, NAnt, MSBuild, and others. So, you should be able to leverage the existing CI work that you have already done. There is also a build type to run a duplicate code checking utility.
It has a system tray tool, similar to CCTray, to show the build status. There is also a Visual Studio plug-in that lets you run the build locally, and only check-in your changes if all the tests pass (if you want to make sure you’re only going to commit good changes). They have a cool feature that lets a developer “take responsibility” for a broken build. This way, everyone won’t think that “someone else” is fixing the problem. They can see that no one has claimed it. The web page shows you a progress bar, so you can see if your build has stopped.
I’ll have a better idea of the limits of TeamCity, as I set up the build servers for several more applications. But it looks to be worth checking out.