TeamCity is a very popular and feature-rich CI tool. There are many other worthy CI tools as well, and it is prudent to compare TeamCity with these other tools. Here, we will be comparing TeamCity with Jenkins and ThoughtWorks' Go. The idea is to look at the biggest features of these two tools and compare them with those of TeamCity.
Jenkins (http://jenkins-ci.org/) is a very popular open source CI tool. It has a huge community around it and is used by many organizations and teams. The biggest advantage of Jenkins is its open source nature and the huge collection of plugins. There is a plugin in Jenkins for almost anything that you would want to do. With an active community around it, more and more plugins are added to tackle newer requirements.
What is probably the biggest strength of Jenkins is also its biggest weakness. To get any sort of work done with Jenkins, one has to install a multitude of plugins that interact in weird ways with each other just because they are written by different authors. To set up and visualize the build pipeline as described earlier, Jenkins will require the use of many plugins such as the Build Pipeline plugin, Build Name Setter plugin, Parameterized Trigger plugin, Copy Artifact plugin, Throttle Concurrent Builds plugin, and Promoted Builds plugin. That are a lot of plugins that you need to learn about and configure appropriately. It also doesn't help that there are many plugins to achieve the same thing, thereby adding to the confusion. With various plugins that need to work together, which were probably not tested together or even intended to work together, it becomes a pain to set up complicated pipelines with Jenkins. Not to say that complex setups aren't possible, but they could have been easier.
The following screenshot shows a sample build pipeline as visualized by the Build Pipeline plugin:
Jenkins is also not an ideal CI server for some platforms/technologies such as .NET. While there are some plugins available, there is not a whole lot of support for such platforms.
TeamCity comes with the right amount of bundled features to give you the feel that the platform of your choice is a first class citizen in your CI server. You also get the features needed to set up and maintain complicated pipelines, and just like Jenkins, TeamCity can be extended with plugins through its plugin API. As mentioned previously, there are a lot of plugins available for TeamCity as well, and many of these are open source too.
Go (http://www.go.cd/) is an open source CD/CI tool from ThoughtWorks Studios. It is a descendent of CruiseControl, one of the earliest CI servers. Go is available for free, with an option to buy commercial support.
Note
Go was a commercial tool but has been open sourced recently. The license terms for Go were very similar to that of TeamCity and allowed small teams to use Go for free.
Pipelines form the heart of Go. It has been designed with the build/deployment pipeline in mind, and as such, the visualization and configuration of pipelines is first class. There is no need to wire different stages of a pipeline manually, as they all fit together automatically. The following screenshot shows the pipeline visualization of Go in action:
Go's plugin API is very limited and so is the number of plugins. The support for platform-specific task runners is very minimal at the moment. While all of the CI servers that we have talked about so far support the ability to run any arbitrary shell commands from the builds, it is good to have specific runners for specific tools. Having a Maven runner, for example, means that the setup is straightforward. One can specify the POM file, the goals, and other required parameters in the appropriate fields, rather than having to specify the exact command line in a shell runner.
In general, Go can be seen to have a limited set of features and doesn't provide a lot of flexibility. While tools such as TeamCity and Jenkins can be bent to meet our peculiar requirement, we might find that doing so with Go is not possible. This is mainly due to two reasons: the feature set of Go is small (but growing) and the developers of Go want the users to follow certain practices, hence restricting the options available. For example, in Go, templates can only be created for a pipeline. In TeamCity, we can create a template at the build configuration level (equivalent to a stage in Go).
The comparisons given here, obviously, aren't extensive but give you an idea about the most important advantages and shortcomings of the different tools. This can be seen as a starting point of your investigations into these tools.