I had a chance to install and play with JetBrain’s new Team City beta today. Team City at its most basic is a Continuous Integration server. Continuous Integration (CI) systems are used to help manage a team’s software development process. Every time a developer checks in code, the CI server will check out the code from the source control system, compile the code, run unit test and perform static analysis and code coverage. This is a great way to back up your development process to ensure that you always have a working source tree and development is never held up because of mistakes.
There are other CI systems available, for example, in the past, I’ve used and liked CruiseControl. It is a very capable system that uses Ant build files to compile and test your code. It’s also Open Source and free.
I want to look at a couple of things that I really liked about Team City that make it shine.
Team City Configuration
The first part is the installation and configuration. It’s dead simple.
Team City is distributed as a WAR file, so if you already have a Servlet container like Tomcat up and running it’s as easy as dropping the WAR file into the webapps directory and deploying it through the management interface.
After the installation all of the configuration of a project can be done directly through the web interface, which is very nice compared to hand editing XML files that is often the case in other CI systems like CruiseControl.
The only gotcha is that in addition to the Team City itself, you have to install one or more Build Agents (this is really a feature, more on that later). I skipped this step at first and of course nothing would compile. Directly from the web application you can run either a Java Web Start or a Windows Installer application that will install a Build Agent on the computer. In my case I used the same computer where I was installing Team City – in a more intensive environment, it might make sense to install it on a different machine.
Multiple Build Agents
While it’s an extra step at the beginning, having multiple Build Agents is a really great idea. You can use many machines to build your projects spreading the load around to different machines. This is especially great if you have big project with lots of unit tests (you do have lots of unit tests right?) or just a bunch of projects and configurations that you would like to build. As software developers know, compiling code and running tests is a pretty intensive activity. Spreading the load around means that you can do more concurrent builds. This is a great way to decouple where things get compiled and tested from the centralized management application. This way you don’t have to have multiple instances of the CI system running on different machines if you want to load balance them.
Not only is the server itself multi-platform, thanks to it being written in Java, but Team City can compile and test both Java and .NET code. It can use a number of different configurations for compiling and testing. In Java, it can currently use Ant, Maven and Idea build files. On the .NET side of things, it can use MSBuild files and Visual Studio 2005 Solution files.
In addition to compiling code for these platforms, it can use either JUnit or NUnit for running Unit Tests as well. I really like this aspect of it because it offers shops that do more than one language a way to use the same systems for all of their development. At work we do both .NET development and Java development for our clients, so this makes a lot of sense for us. At least in the consulting world, this is a big win.
Team City has IDE integration built in. Currently it only supports Idea (why would you need anything else?) but they have already announced that for the 1.5 release they will support Eclipse, Netbeans and Visual Studio. There are a number of features that you need to have the Plugin installed to use, so for the short term Team City will be an OK solution, but not a great solution for non-Idea users.
Delayed Commits is quite possibly the best idea in Team City. It basically allows you to “commit” your changes to the server, but only have them checked into the source control repository if they compile and test correctly. No longer do you have to wait around for the CI server to report back that your checkin was successful before going to lunch or going home for the night. You can now Delay Commit your code and if everything works out it will be checked in for all the other developers to pull down, if not no one will be the wiser and you will fix any issues when you get back to your workstation.
The UI is also very nice. They effectively use AJAX techniques to have a really nice user experience.
While this product is in Beta still and I haven’t had a chance to use it in anger yet, I think it’s a very promising tool. JetBrains has a great track record in delivering excellent products. I’m a huge fan of Idea and I can’t do .NET development without ReSharper. I think they have another hit on their hands with Team City. I haven’t heard anything about pricing yet, but the JetBrains stuff seems to usually be affordable.
As an aside, I have no intention of taking anything away from CruiseControl. It is still a great application as well (did I mention it was free).
(Jet Brains people, Yes, I’m willing to take paid endorsements :))