Here it is at last, an unofficial and very poor quality comparison between two of your favourite CI build tools Jenkins and TeamCity. Which one should you choose and why?

Introduction

Jenkins is free and open source and written in Java. It is probably the most widely known and used CI build system and has been around since 2011.

TeamCity by Jetbrains is a commercial product and is also written in Java using a SQL Server backend. It has been around longer than Jenkins at 2006 but both are clearly established systems.

Pricing

When you are setting up your devops environment, you might only need an agent or two but once you start growing, some of the commercial offerings start getting expensive fast. With Jenkins that is not an issue, which is great.

TeamCity starts with a free tier that gives you 3 agent licences and 100 build configurations. Certainly enough for most people when starting out but as soon as you need additional agents, they come in at around $300 each. Now if you need that many, you should be making some money enough to pay for these but that is certainly not guaranteed and the worst thing, of course, is that you might only need the additional agents very infrequently so paying the extra is slightly annoying. This pricing really doesn't scale. For a large outfit needing 100 agents, you are paying something like $25K, which seems a lot.

If you want support, you need to buy the enterprise licence, which for 3 agents is around $2000 and includes a year of upgrades and email support.

Support

Jenkins does not provide official support channels other than listing a number of companies who can support you. This probably works OK since I suspect that having a more local company or one in your market vertical is probably better than a single support channel. The pricing will obviously vary depending on what is on offer and what you need.

Support is included for both systems on forums but if you want email support with TeamCity, you need the enterprise licence.

Personally I have not used Jenkins support but I have used TeamCity. I find the response times very erratic, sometimes not receiving an answer for weeks and other times very quickly. The staff do seem to know what they are talking about once you do get an answer.

Configuring for .Net

TeamCity definitely has the better .net support. You can install the .net plugin and install MS build tools on the agent and it is pretty easy to add and configure .Net steps.
 
Jenkins on the other hand has minimal .Net support. The whole interface, to be honest, is very unappealing lacking basics like directory browsers for directory fields. In most cases, you need to use the "Windows batch command" box and just type in command line entries, which is annoying, because invariably you would need to copy and paste these as opposed to a nice plugin that helps you out by asking for what you need and passing to the command line correctly.

The UI Generally

I would also say that TeamCity wins in general. The layout is generally logical but there are definitely some real areas of concern. Firstly, the UI is very slow and unresponsive. Pages can easily take seconds to load, which is a shame when you are trying to update a lot of things very quickly. It also has issues with asynchronous updates sometimes working and sometimes not. For example, you are looking at a project page and someone starts the build, the right-hand side should update with the new build appearing. Sometimes it does, sometimes it doesn't.

The administration of TeamCity is also clunky. They mix features in the main content area with dropdown menus in some places and the fact that to edit some things, you need to go to the correct level in administration. You can't, for example, copy a build configuration from inside that build, you have to go up to the parent group and copy it from there.

Jenkins has avoided some of this by keeping really simple. In place of some of the nicer functionality that TeamCity has, Jenkins just has boxes. Lots of boxes. Whereas in TeamCity you add steps in a nice list that you can go into the steps or go back up to the list, Jenkins just has a massive long list of each step detail in one place. Even the navigation at the top of the build config just scrolls you down to the bottom. To be fair, I have not used it much so it might have been due to the specific test I was running but the interface on the whole looks like it did on day 1 in 2011, which looks like Java from 1998. TeamCity, also runs on Java but at least they make it look more like a web app.
 
Jenkins also has a funny approach to build variables. If you want to inject, e.g. the working directory into a command, you need to use different syntax depending on whether you are running on Linux or Windows and also whether you are running CMD or Powershell. Honestly, the UI could have hidden this but to add to the confusion, some plugins need the variables in a certain style whatever the underlying OS (perhaps what the server should do automatically!)

Another feature which seems very lacking in Jenkins is the ability to set the working directory of each build step. In a Windows batch command, you can CD into a directory but that is very clunky. You should be able to set the directory like you can in each type of TeamCity step because it just makes sense that way.

Plugins

Both systems have many plugins available. Lots of TeamCity's are produced by Jetbrains so they are quite decent. There are also lots included out of the box like DotCover to measure test converage as well as many .Net friendly things like Nuget, Nunit etc. You will probably not need to install any/many additional plugins.
 
On the other hand Jenkins is all about plugins. The server itself provides very little out of the box. You can't have, say, a .Net Build step without a plugin and then all you can find is an Msbuild one which doesn't install any MS stuff, just sets up the command and calls CMD with it. Because all of them are community, the quality is highly variable as you would expect. Some are out of date and unlikely to be updated, others are probably really good. You will need to install plugins to do most things in Jenkins so be warned!

Adding Agents

Like most systems that run Java, adding additional agents always seems a little long-winded. In Team City, you get some instructions that you run after installing Java and some other pre-requisites on the agents. Sometimes you can log in to the agents page on the server and download what you need and you can even, theoretically, push an agent to another machine but of course the setup for that with permissions and ports is not worth the hassle. I'm glad you don't do this very often.
 
In Jenkins, I was confused after first setting it up assuming that the server is not setup as an agent as it is in TeamCity. The UI implied I needed to add one so I did, pointing to localhost, which really screwed up the UI. I think it could easily have dealt with that and checked for localhost or 127.0.0.1 to tell you that you do not need to do this for localhost. Looking at the instructions for adding another agent, it looks like you need to install Java, download a war file and execute it. I don't know how easily that will work.

Performance

Well to me, this one is so important when you have lots of builds. How long does it take to run a build? You would think that running e.g. a .net build on any CI would take roughly the same amount of time because MsBuild runs as fast as it can run but you would be wrong.

To compare Jenkins and TeamCity, I decided to create a Jenkins server, add a build that matched what we already have configured on TeamCity and see whether there was any marked difference. I didn't expect much but there was a lot of difference! A build that was taking around 4m40s on TeamCity only took 2m50 on Jenkins! Yes a whopping 40% speed increase on Jenkins. That is despite the fact that the Team City server is 8 cores and 16GB and the Jenkins one only 4 cores and 8GB RAM - Msbuild only uses 1 core by default as far as I know.

Now we have had suspicious performance issues on TeamCity for a while, I just couldn't understand why unit tests that take, maybe 30 seconds on my developer machine, take a whole minute on TeamCity. Of course, we reached out to support and get sent a load of server tweaking stuff, some of which we did, some of which we didn't understand. That is not really an acceptable response for something that costs this kind of money. I would expect the people who write this to understand it enough to write a tool that prints a report saying "You need to increase that or decrease that" and ideally it should all happen during installation. We ran a trace on the build server and found their SQL database is being hit multiple times per second, causing significant CPU usage for SQL Server even when you are just running a basic build - we found a forum post from someone else with the response, "That is an important part of the system". Great.

The thing is, we are now using the 3 free agents and have some builds that take 45 minutes so reducing that to 25 minutes would be really significant and since build times affect us far more than UI issues, it really is something worth jumping ship for and going for Jenkins.

Conclusion

TeamCity is not crazy expensive if starting out and the UI is much more friendly, particularly for .Net but their performance is unimpressive and the pricing won't scale.

Jenkins on the other hand certainly looks older and lacks some of the niceties of TeamCity but if you know the basics of calling dotnet or msbuild on the command line, it probably won't take you long to create a suitable build so if you are up for that, I would probably recommend starting with Jenkins - you might never leave.