Introduction

I have previously used CruiseControl.NET as my Continuous Integration (CI) and Continuous Delivery (CD) server of choice. I have used this in conjunction with Nant build scripts and Subversion (SVN) as the version control system (VCS). I have setup and configured CI environments from scratch, and introduced CI / CD into businesses where there was previously no CI /CD whatsoever. So I'm more than familiar with CI / CD from a practical perspective.

I was perfectly happy with using CruiseControl.NET, Nant and SVN. Together they worked perfectly well. All of them are best of breed tools that have massively widespread use in the development community due to their levels of maturity, their respective communities and their levels of integration with other tools.

I have recently moved over to using TeamCity (in conjunction with MSBUILD and Team Foundation Server (TFS)) and thought it would be useful to give some of my thoughts on their respective strengths and weaknesses and contrast them. This tip is not intended to be a thorough review of these applications, I am sure that there are already plenty of comparison matrixes already available that show their respective feature sets. Instead, this tip describes the strengths and weaknesses I have found between them whilst installing and configuring them as an end user.

CruiseControl.NET

CruiseControl.NET is an open source CI server from ThoughtWorks (the employer of that notable software guru Martin Fowler). It is written using the .NET framework and is heavily based on its Java based sibling CruiseControl. It has a long history, and is therefore a very mature product. Some might call it the grand-father of all current CI servers, and this wouldn't be in any way insulting. It's an extremely reliable CI tool with an impeccable pedigree. It integrates with many other tools such as Subversion, Git, Mercurial and TFS. It's straight forward to install. Adding build projects requires manually writing the underlying XML code. There is no user-friendly UI for doing this, and this may be a problem if you are not a developer or familiar with XML syntax.

Once setup and configured, then CruiseControl.NET can provide build notification via CCTray which is installed separately from CruiseControl.NET (there is a link to downloading CCTray on the CruiseControl.NET homepage). This is highly configurable and supports many different networking protocols for providing notifications.

When I ran into the inevitable problems, I got lots of help from the CruiseControl.NET community and forums such as StackOverflow. CruiseControl.NET is such a widely used CI server with such a maturity that it correspondingly has a massive user base. I quickly found answers to all my issues and problems.

TeamCity

TeamCity from JetBrains (the same company that brought us Resharper) is a Java based CI server. Being a Windows based .NET developer, I wasn't overly familiar with the way Java works on the Windows platform, but thankfully you don't need to be an expert. You are required to configure a Java environment variable and download and install the JDBC driver for your particular database (in my case for SQL Server). Links to the JDBC driver are provided on the install wizard screen.

So there's one key difference already. CruiseControl.NET doesn't require a database whereas TeamCity does.

Once TeamCity is installed, you can then launch it for the first time and begin configuring it for your environment. I began by setting up the necessary users (both developers and testers). The UI to TeamCity is very simple and easy to use so you shouldn't struggle to find what you need.

TeamCity works differently to CruiseControl.NET in how it actually runs its builds. CruiseControl.NET runs as a Windows Service running on the same server that it is installed on. TeamCity can also run in this manner, but it can also be run on a different server as a build agent. You can have up to 20 build agents running different builds (for more build agents, you need to upgrade to the enterprise edition of TeamCity). This allows TeamCity to run builds for completely different platforms, e.g., running your Linux based build with one build agent, and your Windows based build on another. This separation of concerns took me a little getting used to, but it works very well. You can of course run a build agent on the server itself, but for scalability, it is recommended to run build agents on servers other than on the TeamCity server.

TeamCity is certainly easier to configure. The UI makes adding / editing builds and setting up your different version control systems (VCS) all very simple. I setup our Team Foundation Server (TFS) VCS without too much difficulty. You need to install the TFS client on the server if you intend to use TFS for your VCS.

I did experience an initial problem with TeamCity in that when running a build it was taking a long time to checkout the code from TFS. Apparently, this was because TFS client 2012 (which was the version I initially installed) was known to be extremely slow under certain circumstances. Once I upgraded this to TFS client 2013, the problem disappeared.

Comparison

Summary

Both CI servers have their strengths and weaknesses, and each one is therefore suited to different sets of requirements. I wouldn't say that one was better than the other, just that one may be more suited to a particular set of requirements than the other. For enterprises developing across heterogenous platforms where future scalability is a requirement, then TeamCity may be more appropriate. For enterprises developing on single platforms, CruiseControl.NET may be more appropriate. Feel free to leave a comment if you would like me to further elaborate on anything within this post.

TeamCity vs Cruisecontrol.NET