Jetbrains TeamCity vs. Jenkins

I have been using Jetbrains TeamCity for a large number of years pretty much in lieu of many other continuous integration build systems including Team Foundation Server.

However, I recently had the opportunity on a recent project to work with Jenkins as part of a migration to TeamCity so I thought this was a perfect way of comparing and contrasting the 2 platforms!

1. First up, from a visual perspective, Jenkins uses a lot more pictures/images/icons than TeamCity.  TeamCity is a rather text-heavy web application and from a visually appealing perspective, is not very pleasing to the eye.
2. Both Jenkins and TeamCity are built on Java and support multiple platforms including Windows. 
3. Both platforms are free, but TeamCity has a limitation of 20 build configurations and 3 build agents.  You can purchase an additional 10 build configurations for a nominal cost of $299 or buy an Enterprise Server license for $1999 which offers unlimited build configurations. 
4. Both Jenkins and TeamCity support plug-ins, however, Jenkins seems to have a wider variety of plug-ins available for the platform than TeamCity.  On the other hand, TeamCity also has a great deal of functionality built directly into the platform that Jenkins would otherwise leverage through a plug-in.
5. Next up, in terms of overall ease-of-use and usability, TeamCity wins hands-down! 

Here are some of the things I noticed immediately:

1. When I want to copy a project in Jenkins, I have to select "Copy existing item" and then MANUALLY  type in the name of the project I wish to copy.  In TeamCity, I simply select the project/build configuration I want to copy and from the "More..." menu item, choose "Copy build configuration"
2. When creating a new item in Jenkins, I am not presented with an option to create a "build configuration template" which is a reusable template for creating future build configurations.  TeamCity presents the option to create either a build configuration or a build template directly from the Project Settings page.
3. In order to create a build configuration, TeamCity provides a wizard-like navigation to configure the various aspects of a build configuration while Jenkins provides a very simple (if not downright primitive) top-down layout for displaying all of the build configuration settings.
4. When creating builds in Jenkins, you can create a parameterized build, but you cannot easily parameterize individual build steps (such as the Execute Windows batch command build step)!  In TeamCity, every single build step is capable of accepting parameters including the Command Line build step.
5. Jenkins has no concept of VCS Roots.  Instead, a single VCS repository has to be configured for each build configuration that you create.  TeamCity provides a centralized repository of VCS Roots which allows you to configure 1 or more VCS Roots which can then be shared readily among all of your build configurations.  This is particularly handy if you are using build templates or builds which need to be chained.
6. After a check-in occurs triggering a build, Jenkins will display the check-in comments from the associated check-ins, but TeamCity will not only display the check-in comments and the person who committed the check-in, but also provide you with a diff view of the files that were changed as part of the check-in!!
7. TeamCity offers built-in issue tracking integration with JIRA, Bugzilla and YouTrack.  https://confluence.jetbrains.com/display/TCD9/Integrating+TeamCity+with+Issue+Tracker   TeamCity also offers plug-ins for various other issue tracking systems such as Team Foundation Server. https://blog.jetbrains.com/teamcity/2014/11/integrating-teamcity-and-visual-studio-online-work-items/
8. TeamCity also allows you to store your TeamCity project settings in a variety of source control repositories such as Git, Mercurial, Perforce and Subversion.  https://confluence.jetbrains.com/display/TCD9/Storing+Project+Settings+in+Version+Control
9. Jenkins has the option to view the Console Output, but TeamCity has not only the option to view the build log, but also to be able to download the build log for a further detailed review!  You can even download the full build log as a large text file or a zipped version of the build log!
10. Jenkins has no option to name any of your build steps to distinguish what they are doing.  The only information you get about build steps in Jenkins is what they are such as "Execute Windows batch command" or "Invoke Ant" etc.  TeamCity allows you to name each of your build steps to better discern what each build step is actually accomplishing.
11. When creating build triggers in Jenkins, you have to manually type in syntax to specify a build schedule (even for the Poll SCM option).  However, with TeamCity you get a nice User Interface by which you can choose options such as a VCS Trigger (which will poll the VCS every time a check-in occurs), or use a Schedule Trigger which allows specifying the schedule for which a particular build configuration will run such as daily, weekly or advanced.
12. When creating a build chain or build dependency, once again Jenkins requires you to MANUALLY type in the name of the project that is part of the build chain, while TeamCity allows you to easily choose among the various existing projects.  
13. Once you configure build steps in Jenkins, there is no easy way to re-arrange the order of the build steps.  TeamCity allows you to easily drag and drop the build steps in order to re-arrange their order.
14. In Jenkins, the only option to prevent a build step from executing is to Delete the build step.  However, TeamCity allows you to easily disable a build step rather than simply deleting it.  Therefore, if you are copying a build configuration or using a build template, you can selectively modify your build configuration to disable certain build steps while still inheriting from the parent build template.
15. Jenkins has no built-in build step for building Visual Studio solutions while TeamCity not only has a built-in build step for Visual Studio solutions, but can also auto-detect Visual Studio solution build steps based on the source control repository as well as even NuGet build steps!!
16. In Jenkins, there is no option to copy an existing build step directly.  Instead, you have to create a brand new build step and then copy and paste the appropriate commands into the new build step.  However, in TeamCity, you can directly copy a build step and then modify/edit as needed to suit your needs.
17. In Jenkins, when you create a build step, there is no option to change the type of build step once it has been created.  Instead, you have to delete the build step and create a brand new one.  However, in TeamCity, by simply choosing the type of build step from a drop down list, you can change the build step from something like a Command Line Build Step to a PowerShell Build Step!  This is extremely convenient when you want to provide more sophisticated functionality and need to switch to something more powerful such as PowerShell.  TeamCity keeps all of your information intact while you begin the process of switching it over to a PowerShell script instead.
18. When you view your build steps in Jenkins, you can only view them top-down and Jenkins provides no details as to how many build steps in your build configuration.  However, TeamCity provides you with a good visual of all of your build steps allowing you to perform a variety of actions on them such as reordering, editing, disabling, copying or deleting them as well as a left hand navigation view which tell you how exactly how many Build Steps exist in your Build Configuration!

This is just a small sampling of the differences between Jenkins and TeamCity.  Once you begin truly evaluating TeamCity for yourself, you will soon discover that TeamCity will also be your Continuous Integration build server/platform of choice!!