Answers: <p>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.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-04T21:09:41.027Z
Answers: 2017-04-04T21:09:41.027Z
Answers: Adrian
Answers: <p>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.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-05T03:19:58.690Z
Answers: 2017-04-06T16:32:29.780Z
Answers: 2017-04-06T16:32:29.780Z
Answers: matthewcummings516
Answers: <p><strong>TeamCity :</strong> </p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p><strong>Jenkins:</strong></p>
  
  <p>Battle tested and Extensive.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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).</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>YMMV</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-07T14:48:47.913Z
Answers: I'd add on Jenkins side the possibility to actually contribute to existing plugins or write your own one for custom functionality. https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-04-07T17:01:50.337Z
Answers: True, though the same is also true for TeamCity (see below) 
   However Jenkins does make it possible to hack the core which is not true for TeamCity.   May or may not be important depending on availability of Java progs in your team and your IT environment
  https://confluence.jetbrains.com/display/TCD9/Developing+TeamCity+Plugins.
Answers: Newtopian
Answers: CC BY-SA 3.0
Answers: 2017-04-07T14:12:28.010Z
Answers: 2017-04-07T14:12:28.010Z
Answers: Newtopian
Body: <p>These tools seem to share very similar characteristics. </p>
  
  <p>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? </p>
  
Comments: CC BY-SA 3.0
Comments: 2017-04-02T17:15:01.747Z
Comments: Related: http://devops.stackexchange.com/questions/141/key-attributes-of-continuous-integration-ci-software?rq=1
Comments: avi
Comments: CC BY-SA 3.0
Comments: 2017-04-02T17:16:25.587Z
Comments: I would like to recommend that your headline question match the question in the body a bit closer. You aren't asking for all differences, just the differences which would make moving between them difficult?
Comments: avi
Comments: CC BY-SA 3.0
Comments: 2017-04-04T14:43:14.343Z
Comments: Realted blog post: https://www.upguard.com/articles/teamcity-vs.-jenkins-for-continuous-integration
Comments: Tensibai
Tags: <jenkins><continuous-integration><teamcity>
Title: What are the main differences between Jenkins and TeamCity if one is used to working with Jenkins?
UserDisplayName: Ricardo Herrera
ThreadText: # What are the main differences between Jenkins and TeamCity if one is used to working with Jenkins?
  
  (Asked by: username_0 on 2017-04-02)
  
  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?
  
  **Tags:** jenkins, continuous-integration, teamcity
  
  > **Comments:**
  > **username_1**: Related: http://devops.stackexchange.com/questions/141/key-attributes-of-continuous-integration-ci-software?rq=1  
  > **username_1**: I would like to recommend that your headline question match the question in the body a bit closer. You aren't asking for all differences, just the differences which would make moving between them difficult?  
  > **username_2**: Realted blog post: https://www.upguard.com/articles/teamcity-vs.-jenkins-for-continuous-integration  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_5 on 2017-04-07. Score: 8 | Accepted answer
  
  **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
  
  > **Comments:**
  > **username_6**: I'd add on Jenkins side the possibility to actually contribute to existing plugins or write your own one for custom functionality. https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial  
  > **username_5**: True, though the same is also true for TeamCity (see below)   However Jenkins does make it possible to hack the core which is not true for TeamCity.   May or may not be important depending on availability of Java progs in your team and your IT environment https://confluence.jetbrains.com/display/TCD9/Developing+TeamCity+Plugins.  
  
  ---
  
  ### Answer by username_3 on 2017-04-04. Score: 6
  
  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 by username_4 on 2017-04-05. Score: 4
  
  I agree with username_3 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.
  
  
  ---
  
  