Considering TeamCity for Continuous delivery? Here is what you need to know

Apr 4, 2017 | Announcements, Migration, MSP

The practice of Continuous Integration (CI) and Continuous Delivery (CD) allows projects to integrate, test and release software in short cycles. Along with version control and automated tests, CI/CD forms the backbone of modern software development projects. Among existing CI/CD tools, Jenkins has emerged as the de-facto leader. Jenkins, which began as a collaborative and open source project at Sun Microsystems under the name Hudson, was quickly adopted by a large user base and has helped refine and standardize this field. Recently, more alternatives (like Atlassian’s Bamboo and Amazon’s CodePipeline) have emerged as the field has become more mature and refined. TeamCity, from Jetbrains, stands out in this arena, and DevOps engineers and administrators would be wise try TeamCity when evaluating the available options.


Traditionally, Jenkins has been a bare-bones CI tool, supporting only the most basic features and relying on an extensive ecosystem of plugins to achieve common tasks. With the release of Jenkins 2.0, project owners have reconsidered this approach and have started to pre-bundle basic functionalities in the installation package. Although there are Jenkins plugins available for anything imaginable, installing and configuring them can be an extra hassle for administrators. In this regard, TeamCity appears a well-developed CI tool that natively and seamlessly supports most basic features.

Integration With Version Control

Foremost among TeamCity’s attractive features is superior integration with your version control system. TeamCity allows you to define “VCS roots” for your projects, where you can wire up your source repository. Extra flexibility allows you to configure what branches to track and when to trigger a build and add custom checkout rules. Adopting standard practices, like feature branches and pull requests, are extremely easy. Developers will love the display of changes per build and difference viewer, which is integrated into the UI. Another killer feature is the Pre-tested Commit, which allows developers to test the feature before committing to it.

Build Chain Management

A typical use case for adopting a CI tool is creating a chain of build steps corresponding to various stages of release. TeamCity adopts this concept into its design and layout. It is easy to setup build chains with dependencies. Every project consists of build configurations, and each build configuration can be broken down into individual build steps. Before the introduction of pipelines in Jenkins 2.0, this was an extremely arduous task in Jenkins.

Artifact management

Jenkins relies heavily on plugins to manage artifacts (output files created by the build process). Usually, in Jenkins, the files are uploaded to an externally managed repository. However, as is often the case with most build chains, the artifacts from intermediate steps only need to be transported to the next step. TeamCity elegantly addresses this: the artifacts from one step can be made available to the next step without any additional effort. There are also options to inspect and download artifacts of past build runs.

Pipeline As Code

A recent trend in computing is to capture different elements of digital infrastructure in code, where they can be subjected to standard practices, like version control and review. In the CI/CD domain, this trend has manifested as the Pipeline as Code concept. Jenkins has made a foray into this concept, in which users have the option to develop pipelines in Groovy Scripts. However, TeamCity is catching up fast. Older versions of TeamCity supported storing configurations as XML, but newer versions have added support for using Kotlin (Jetbrains’ own scripting language)

Cloud, Containers and Elastic Agents

A CI/CD setup consists of a build server, which kicks off the build process, and one or more build agents, which run the build. A dynamic setup, where build agents are set up or torn down according to demand, is highly preferred to a static setup. In this case, the ability to seamlessly work with your Cloud solution provider or data center virtualization software is essential. TeamCity supports integration with EC2, Azure and VMWare. However, Jenkins has taken an extra leap and has support for build agents running in Docker containers. Although TeamCity doesn’t support this out of the box, there are plugins available that allow for it.

User Interface

Jenkins has the bare minimum to offer regarding its user interface and experience, which probably has never been an issue with its target audience. This mindset is rapidly changing, however, as Build Management becomes an integral part of the software development life cycle with more non-technical team members relying on the CI tool. TeamCity offers a well-designed, feature rich UI that both developers and project managers will love. Essential ideas, like build chains, run logs and version control, are brought together in an intuitive and easy-to-use manner.

Support and Documentation

Regarding support, Jenkins relies on the shared knowledge of its large user base. The open-source nature of the project gives Jenkins a leg up here, but the official documentation for Jenkins leaves much to be desired; it is never up-to-date and is full of gaps. Hop on over to the TeamCity documentation page, and you will find well-maintained, up-to-date and complete information. Also, there are support forums, issue trackers and direct support for enterprise customers.

Installation and Maintenance

TeamCity installation is extremely simple and offers customized installation packages for Linux, Windows and Mac servers. Essential features, like Security and Audit, are offered out of the box. The Jenkins installation process has matured over past releases. However, extra configuration steps are needed to make it work properly in an enterprise environment. While Jenkins stores all information in local files, TeamCity stores it in the database of your choosing (with an embedded HSQL option). This can be crucial to implementing additional steps, like performance tuning and backup.


Let’s face it. Cost is probably the most crucial determining factor for most. Yes, TeamCity is commercial, and you do have to pay for an enterprise license, but in this case, you really do get what you pay for. For limited uses, there is a Professional Server License (supports 3 build agents and 20 build configurations).

Note: The above analysis compares Jenkins Version 2.32.3 with TeamCity Version 10.0.4 (The most recent releases as of this post)


nClouds is a cloud-native services company that helps organizations maximize site uptime, performance, stability, and support, bringing out the best of their people and technology using AWS