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
- I couldn't find answers with quite the same ease with which I had found them for CruiseControl.NET. I posted several question on StackOverflow, of which one received a response. The TeamCity developer forum and bug tracking web application (Youtrack) are better places to post your questions. The TeamCity community doesn't seem to be as large as that for CruiseControl.NET so finding answers to my questions did take longer.
- Both CI servers are highly configurable and can be used with a multitude of different toolings and ecosystems. CruiseControl.NET arguably sits better with a Windows environment and for me was quicker and easier to install. TeamCity however runs perfectly well in a Windows environment but being unfamiliar with a Java environment was the cause of some confusion during the installation phase. If you're familiar already with Java, then this shouldn't pose a problem.
- TeamCity was easier to configure with its simple UI. There is probably more work initially in setting up your CruiseControl.NET builds due to the fact that you have to do this manually by editing the underlying XML files, whereas in TeamCity you create your builds using the UI.
- TeamCity scales incredibly well, and is arguably the better choice for the larger enterprise team running multiple builds with large teams. The concept of the build agent allows builds to be spawned off to separate servers so they don't create lag on the CI server.
- CruiseControl.NET doesn't require a database and therefore poses no barriers to installation or maintenance.
- CruiseControl.NET runs on IIS rather than Apache Tomcat. For a Windows .NET developer such as myself, this was obviously a benefit. Again, if you are familiar with the Java environment, then this shouldn't pose any problems.
- If you intend to extend the functionality of your chosen CI server, then obviously CruiseControl.NET would be the obvious choice for a .NET developer. Whereas TeamCity would be the obvious choice for the Java developer.
- TeamCity has a wide range of plugins available covering a wide range of functionality, so you may find that your specific requirement already has a solution via a plugin. There is also a plugin for Visual Studio, something which I would have thought would have been available in CruiseControl.NET (but sadly at the time of writing is not).
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.
