What are the main differences between Jenkins and TeamCity if one is used to working with Jenkins?

Question

These tools seem to share very similar characteristics.

How complicated would it be to start using TeamCity after getting used to working on Jenkins? Are there specific concepts one needs to be aware of?

Answer 1

TeamCity :

It does look nicer, if this is important for your team then it should definitively weight in. That said, if it is VERY important than you probably will end up creating tools or some sort of dashboard overlay to support your team at which point what you really want is the one with the best API. Have not tried Jenkins API so I cannot compare, the TC API though should get you what you need.

Their support is pretty good, the guys respond relatively fast and are courteous. However that does not mean you will get what you want. If you use the system in an unconventional way you can very well get your bug put on the shelves... happened to us. At which point it becomes quite frustrating to use, you are faced with a black box leaving little alternative than to work around it. At this point things can get hackish and ugly.

It is generally pretty quick to get done what you want and the log interaction quasi API is a very nice feature if you do a lot of custom scripting in your pipeline.

Jenkins:

Battle tested and Extensive.

But it is somewhat less pretty, would not go as far as saying it is ugly though, one could say that functionality comes before appearance.

I'm pretty sure you can find private paid support plan by third party companies if you look around. If this is important for your shop don't just block at the "OpenSource" part of the deal, the community is quite expansive.

Lots, I mean LOTS of plugins. Again don't just just limit yourself to the official channels, lot more plugins can be found in github and other places.

I found both to be about equally fast to get started with, though with Jenkins you might need to be more dynamic with plugins than with TeamCity. So if you have a tight IT department and wont get admin access to the server this could pose a problem. Compounded by their much faster release cycle than TeamCity (weekly).

I found that Jenkins does support more release cycle paradigms than TeamCity. Might be easier to find a process template out of the box that is a closer match to what you have in mind. I say this with reserves as I have not dealt with TeamCity for 2 years now.

I personally prefer Jenkins mostly because I am biased towards Open Source for such tools and in a lesser degree because I found it's structure and config mechanism agree more with me.

YMMV

Answer 2

On the whole, the user experience is pretty similar. TeamCity has a prettier UI, but isn't particularly easier to use. In terms of functionality, the two are effectively equivalent. Most of the terminology is the same as well.

The plugin ecosystems are fairly different, however; you'll definitely want to look at what plugins are available for TeamCity to achieve what you're trying to do, as this will likely be the biggest pain point in terms of a transition. If you're used to running certain Jenkins plugins, you'll need to learn a) what functionality is provided by TeamCity without any plugins needed, and b) what plugins are available to add any remaining functionality, and how they differ from plugins you're used to in Jenkins.

Answer 3

I agree with Adrian on most points. TeamCity's UI is definitely prettier and you get a lot more built-in functionality out of the box with TeamCity than with Jenkins. But Jenkins is open source and while the quality (and doc) varies a lot from plugin to plugin, the ecosystem is extensive.

I've been using Jenkins for years and just started using TeamCity recently. For example, setting up dependent jobs is much simpler and more intuitive in Jenkins than it is in TeamCity.