patternMinor
What are the main differences between Jenkins and TeamCity if one is used to working with Jenkins?
Viewed 0 times
themainwhatarejenkinsusedwithworkingdifferencesone
Problem
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?
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?
Solution
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
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
Context
StackExchange DevOps Q#756, answer score: 8
Revisions (0)
No revisions yet.