For several years we have been using TeamCity to achieve Continuous Integration amongst the development team. It became apparent that Jenkins stood out in terms of both features and popularity of uptake. For that reason we chose to compare Jenkins with TeamCity.
At Revium, for several years we have used an application called TeamCity to achieve Continuous Integration amongst the development team. In recent years, the market for Continuous Integration software has matured, so we felt it timely to review TeamCity against new offerings. Very quickly it became apparent that Jenkins stood out in terms of both features and popularity of uptake. As such, we chose Jenkins for our review.
It’s important to note that the areas of interest we compared are based on our needs at Revium, rather than a full feature by feature comparison. This is by no means a head to head Review.
TeamCity is based on and uses the concept of containers and projects. Containers are used to group projects by client, with each project able to have multiple build environment configurations.
This structure allows TeamCity to present a hierarchical view.
Jenkins is flatter and built around the concept of jobs. The main view provides a single table listing jobs. There is the possibility of grouping jobs with a tab based approach, however this extends horizontally rather than vertically. Attempting to achieve improved grouping through the use of plugins provided only incremental improvement.
Out of the box, TeamCity is more functional, has less need for plugins and provides a nice visual interface to work with.
Jenkins has traditionally been rather developer oriented, and as such, to date lack a mature and polished interface of the more commercial products. The demands of today have helped influence some improvements in Jenkins, resulting in 2.x and new concepts such as Blue Ocean interface and the Pipeline job type.
Blue Ocean is an optional new plugin that provides a new interface for Jenkins. It aims to replace the traditional user interface with a richer and more visual user experience. At the time of review, it was of no use due to supporting only Git which is not currently the source control type used on the majority of our projects. Blue Ocean is currently version one with many items on the roadmap to be completed. IT was also built for the new pipeline job type. Pipelines appear powerful but are still in early days. It will be interesting to watch Blue Ocean and pipelines mature and perhaps review in the future.
Jenkins has a multi config job type and also some plugins to enable extra functionality. These add complexity and can be difficult to fit into the multi environment structure.
The multi config job type runs all variations at once. This makes it appear more suitable for different platforms like desktop app and mobile app at once rather than stage and production environments. Plugins do try and work around this but doesn’t seem a nice approach as it’s not a natural fit and adds complexity.
In Jenkins, it would seem easier to have a single job for each environment type and group using the functionality mentioned earlier. TeamCity’s container and project structure comes in handy here and is much preferred. It also saves a lot of out of the box configuration overhead.
TeamCity provides a good summary of pending changes and pulls in details from source control to provide a summary of what those changes include.
Out of the box Jenkins does not provide any indication to what pending changes are ready to be actioned. A plugin is available but didn’t seem to be in a good state. It had broken images on the webpage, URL’s appearing to be hard to perhaps the developer’s environment / assumed default configuration and information not updating even though everything was configured.
Jenkins has some basic statistics out of the box and can be enhanced via yet more plugins. TeamCity seems to come across nicely by providing a good mix of system and project overview information. TeamCity definitely provides the edge here.
Overall it seems TeamCity is a better fit for our needs at this stage. Although Jenkins has limitations, as project requirements and technologies change, so too may our need and use for Jenkins in future.