Jenkins is an open source continuous integration tool, while TeamCity is a proprietary offering from JetBrains. TeamCity is easier to configure and more straightforward to use, while Jenkins has a rich plugin ecosystem and integrations.
That's TeamCity vs Jenkins in short but continue reading for a deep dive into continuous integration and why more and more software development teams are using these tools to speed up their release cycle.
Continuous integration, source control nad build management are formative concepts behind DevOps, driven by the need to regularly integrate new and change code in the master repository of version control systems like Github or Atlassian's Bitbucket. Continuous integration is often combined with continuous delivery to achieve faster and more stable build processes with automation.
With continuous integration, teams compile software and run it through a series of tests that mimic the production environment to ensure a successful build when pushed to production. The logic behind this is simple but only came in response to problems in the traditional deployment cycle. The more you can build and test during development, the less software engineers have to worry about pushing to production. Instead of pushing once a quarter, continuous integration, continuous delivery and testing make go-live another simple routine deployment.
TeamCity and Jenkins are CI tools that allow developers to integrate code branches during the development process and run a series of automated tests against them. Each team member gets immediate feedback about the production readiness of their code, even if they just changed a single line. That way, everyone can push to production while the process of building, running tests and deploying is done automatically so they can focus on the next feature or bug fix.
While both tools cover much of the same ground, they do so in different ways. This is because Jenkins is an open source project while TeamCity is a proprietary offering from JetBrains. In our comparison, we'll show you how they stack up and discuss some of their similarities, differences and what makes each a good fit for different environments. Both offer great support and documentations but again there are differences in depth and quality.
Table of Contents
- What is TeamCity?
- What is Jenkins?
- Side-by-Side Scoring: TeamCity vs. Jenkins
- Scoreboard and summary
- Other continuous integrations tools to consider
TeamCity Interface (Source: jetbrains.com)
TeamCity's slogan "Powerful Continuous Integration out of the box" speaks to what they offer in their solution over and above a free option like Jenkins: out of the box usability with excellent build history, source control and build chain tools. Its slick graphical interface and ease of use features make it more palatable for some new to continuous integration. TeamCity runs in a Java environment, usually on an Apache Tomcat server, though it can be installed on both Windows and Linux servers. TeamCity offers equal support for .NET and openstack projects, integrating into both Visual Studio and IDEs like Eclipse.
TeamCity has converted many Jenkins faithful with its interface and secure default configuration. JetBrains offers a free edition as well, with up to 20 build configurations and 3 build agents. Scoping beyond that requires their commercial "enterprise" edition.
Example of the Jenkins 1.x web interface. (Source: wiki.jenkins-ci.org)
Jenkins is an open source Continuous Integration server and Continuous Delivery tool used widely and considered by many to be the de facto standard for CI servers. Jenkins also runs in Java, so you can install it on Windows, unix or Linux operating systems. Highly extensible and with a gallery of plug-ins readily at hand, Jenkins offers granular customization for any size CI operation. But as you can tell by comparing the two screenshots, Jenkins' interface is more reminiscent of the last generation of web applications.
Jenkins was previously the Hudson CI server. After Oracle’s acquisition of Sun, the source code was forked and Oracle continues development under the Hudson name.
(Example of the Jenkins 2.0 interface, Stage View. Source: jenkins.io)
If you're considering CI, you're considering Jenkins. But like many feature rich, open source software projects, Jenkins gets a reputation for having a difficult setup and configuration process, which is the gap TeamCity tries to fill with its commercial offering.
Update, Friday May 13th: Jenkins 2.0 has improved the user interface significantly.
Really, both of these are quite capable products. Jenkins leads the way for CI, as it has for some time, so its feature set is quite rich, offering many different ways to achieve both CI and continuous delivery.
TeamCity may not be exactly matched with Jenkins when it comes to the capability set, but the differences are small and TeamCity will serve most CI operations just as well.
Good news for TeamCity, who wouldn't be able to compete if they didn't offer most of the same capabilities as their open source counterpart but does supports different platforms such as Ruby, .NET, and Java as well as first class Docker support.
(TeamCity vs. Jenkins --- Capability Set)
TeamCity's interface, simple setup and out of the box security give it a leg up over Jenkins when it comes to ease of use. The selling point for any commercial alternative to an open source product is that it reduces the administrative overhead by visualizing or otherwise simplifying access to the functionality set.
This isn't to say that Jenkins is not usable, because it is, and has been used well by many people, but for those who can afford it and don't have the time or inclination to learn Jenkins in and out, TeamCity offers a more usable interface for the same basic technology.
(TeamCity vs. Jenkins --- Ease of Use)
Both TeamCity and Jenkins have community support available from their website, allowing users of their software to share information and troubleshoot problems collectively, as well as providing a knowledge base to trawl through when looking for specific answers.
Jenkins has a slight advantage here, if only because they have been around longer and as an open source project, Jenkins users rely more on their community for troubleshooting.
(TeamCity vs. Jenkins --- Community Support)
TeamCity is currently on release 2019.1.4, which came out on October 11th, 2019. Their releases have been regular and well documented.
Jenkins' release history is quite impressive, summarized on their change log, with detailed information about each release. Version 2.200 went live on October 14, 2019.
As they make CI products, these companies know the proof is in the pudding, so it should come as no surprise that their release processes are high quality.
(TeamCity vs. Jenkins --- Release Rate)
TeamCity offers two versions of its CI product. TeamCity Professional is free for 100 build configurations and three build agents. Additional build agent licenses can be purchased for $299 and includes one additional build agent and ten additional build configurations.
TeamCity Enterprise allows for an unlimited number of build configurations and licenses start at $1999 for 3 build agents, scaling up to 100 agents for $21,999. Pricing is 50% off for startups and free for open source projects.
As we've mentioned, Jenkins is open source, under the MIT license, and as such can be downloaded and used for free. For this reason, smaller companies may want to approach CI from a "why wouldn't we use Jenkins" perspective.
One potential answer to that question might be because your organization lacks the manpower, knowledge or capability to organize and manage a Jenkins solution. TeamCity offers professional support services, whereas support for Jenkins mostly comes from the community and online resources, though third party companies offer Jenkins-specific professional services.
(TeamCity vs. Jenkins --- Pricing and Support)
Both TeamCity and Jenkins offer a RESTful API. Jenkins' API comes in three flavors: XML, JSON and Python. Jenkins has greater extensibility as nearly every part can be customized as needed. Their extensibility page has excellent resources for almost every kind of possible customization. TeamCity has far less information available on their site, another difference between the commercial and open source offerings; however, TeamCity users seem pleased with the API overall.
(TeamCity vs. Jenkins --- API and Extensibility)
Plugins are the name of the game for Jenkins, who offer hundreds of free plugins, from source code management, to build tools, to language-specific development tools. This pre-existing database of useful plugins makes fitting Jenkins into your environment much easier, hopefully sparing the need for costly in-house or contracted customization. TeamCity also has over 380 free, crowd developed plugins available, which they offer on an as-is basis, outside of their supported commercial product. TeamCity also has great cloud integrations (Google Cloud, AWS, VMWare, etc) as well as 'key' integrations (VSCode, Jira, even NuGet)
(TeamCity vs. Jenkins --- 3rd Party Integrations)
TeamCity boasts a wide range of top companies as customers, including internet powerhouses Twitter, eBay and Wikipedia. Jenkins has no lack of big names on its list of users either, Dell, Tumblr, and Netflix among them. Clearly both of these products are capable of operating at a high level at even the largest scale.
(TeamCity vs. Jenkins --- Companies that Use It)
As with ease of use, the learning curve on TeamCity is shorter than Jenkins as part of the value they offer for their commercial product. People new to CI itself might have an easier time grasping the concepts and procedures in TeamCity's superior interface, instead of adapting to Jenkins' old-style UI. That said, documentation abounds for Jenkins, and salty sysadmins might prefer its Linux-like essence to the proprietary blackbox of TeamCity.
(TeamCity vs. Jenkins --- Learning Curve)
Both JetBrains and Jenkins have external cyber security ratings in the "good" range.
|Ease of use|
|Pricing and support|
|API and extensibility|
|Companies that use It|
|Total||4.3 out of 5||4.5 out of 5|
It's a close outcome, but the big differences between the two products should guide you: do you need an endlessly extensible open source solution that you're willing to learn, or would you rather pay up front for a commercial solution geared to increase usability? Both solutions can run your CI/CD environment well and look to only be improving on their offerings into the future. Keep in mind that CI and CD are great, but stand to be complemented by a visibility solution, such as UpGuard. Ensuring your configurations match your expectations is the important first step toward CI, CD and automation.
There are other CI/CD servers out there. Bamboo from Atlassian is a popular choice. Like Jenkins and TeamCity, it allows developers to automatically build, integrate and test source code then prepare apps for development. Bamboo works seamlessly with other Atlassian tools like Jira (project management) and Hipchat.
Another popular choice is GitLab CI, along with testing and building projects, GitLab CI can also deploy the builds to your infrastructure, giving you an option to track your different deployments by knowing where each piece of code went. The good thing about GitLab CI is that it is offered for free as a part of GitLab. It's as simple as adding a .gitlab-ci.yml file to the root directory of your repository and configuring your GitLab project to use a Runner. Afterwards, every commit or push will trigger the CI pipeline that has three stages: build, test and deploy.
Travis CI is another alternative that provides multiple runtimes (e.g. Node.js or PHP versions), data stores and more. Because of this, hosting your project on travis-ci.com means you can test your library or applications against multiple runtimes and data stores without having them locally installed.
CircleCI is another choice. It's a continuous integration and delivery platform that helps software teams release code by automating the build, test and deploy process. Not alike the other alternatives listed above.