Comparing Jenkins vs TeamCity - Part 1
As some of my closest friends already know, I decided to bite the bullet and switched jobs recently.
As the new company I now work for is really small compared to the one I left, it also means that as a developer I am also involved in more than just programming.
One of the decisions I had to make and implement was selecting and setting up a CI server for continuous building and deployment of our next product.
Having had extensive exposure to CruiseControl, I immediately discarded it as I've developed a particular dislike for this product.
The next alternative I had had any exposure to was Hudson (now renamed to Jenkins) and JetBrains's TeamCity, which I had heard a lot of nice things about. Adding to the mix that first project to hit our CI server would be .NET project, I needed a solution that would run on Windows and build .NET projects using MSBuild.
I settled on Jenkins and TeamCity as the two major contenders.
I would like to point out that this post is full of personal opinions, by no means impartial as comparisons go and should as such be taken with a fairly grain of salt. You might not like it or not agree with my conclusions, and that is entirely your tragedy. I just record my experiences here - YMMV.
JetBrains offeres it as a Professional and Enterprise editions. Professional edition is free and is limited to 20 user accounts and 20 build configurations. With the product you get to use up to 3 build agents and you can purchase more as you develop a need for these.
20 users and 20 build configurations sounds plenty fine for our case, so this is no problem at the moment.
As an OSS project, it is completely free. No strings attached, no limitations, no hidden agendas.
After installer finished running, the server and agent services were installed and running.
Nothing more to do.
To be completely honest, these steps will only run Jenkins instance and as soon as you kill the process, or shut down your computer, Hudson will go down. To finish the installation of Jenkinbs you need to install it as a service on your host machine. The instructions for that vary by platform, but under Windows it is just as simple as following links from dashboard:
Additionally - installing it as Windows service just blew me away - Like it? Take it - Click, click, clickedy-click and Done!
Definitely, Jenkins feels much friendlier towards "just trying it out" and it can not be bad to the developer community - using Hudson, it is not entirely impossible to have each developer running their own Hudson CI instance on their own machine - it is just so simple to set up!
What's more, since it is so easy to set up (and you don't have to commit to it by installing it as a service), it has a real advantage of being the CI of choice for every developer. Every one can run their own Jenkins instance on their computer. And that is good...
This one established some background and covered installation of the server.
In the next post of the series I'll be covering post-install setup of both products
As the new company I now work for is really small compared to the one I left, it also means that as a developer I am also involved in more than just programming.
One of the decisions I had to make and implement was selecting and setting up a CI server for continuous building and deployment of our next product.
Having had extensive exposure to CruiseControl, I immediately discarded it as I've developed a particular dislike for this product.
The next alternative I had had any exposure to was Hudson (now renamed to Jenkins) and JetBrains's TeamCity, which I had heard a lot of nice things about. Adding to the mix that first project to hit our CI server would be .NET project, I needed a solution that would run on Windows and build .NET projects using MSBuild.
I settled on Jenkins and TeamCity as the two major contenders.
I would like to point out that this post is full of personal opinions, by no means impartial as comparisons go and should as such be taken with a fairly grain of salt. You might not like it or not agree with my conclusions, and that is entirely your tragedy. I just record my experiences here - YMMV.
Introduction
First a little introduction of the two products.TeamCity
TeamCity (TC for short) is a commercial offering from JetBrains (the company who have brought to Java development community an excellent IDE called IntelliJ IDEA).JetBrains offeres it as a Professional and Enterprise editions. Professional edition is free and is limited to 20 user accounts and 20 build configurations. With the product you get to use up to 3 build agents and you can purchase more as you develop a need for these.
20 users and 20 build configurations sounds plenty fine for our case, so this is no problem at the moment.
Jenkins
Jenkins (originally called Hudson, until Oracle botched it with the community and got renamed) is an open source CI server implementation that started out as a hobby project by Kohsuke Kawaguchi while he was working as Sun, but has now grown into one of the most popular CI server implementation in the Java community. It has a vibrant community of core and extension developers, rich set of plug-ins that let it do almost anything that a CI build server needs to do.As an OSS project, it is completely free. No strings attached, no limitations, no hidden agendas.
Installing
First things first. Although there are cloud offerings out there that offer CI server configurations, the requirement to build .NET projects, to really try both out, I need to install them side-by side.Installing TeamCity
Here are the steps:- Download the installer for free Professional version from JetBrains - 301 Mb
- Run the installer and follow the steps within
Sit back and wait until TeamCity installer finishes setting itself up. - Answer few more questions like operating port of the build server, set up build agent properties and some more stuff that seemed to have fairly sensible defaults.
- Open your browser and point it to http://localhost:80/ (or whatever port you chose to run your TeamCity server on)
After installer finished running, the server and agent services were installed and running.
Nothing more to do.
Installing Jenkins
- Download the latest jenkins.war [1] - 35 Mb
- Run fom console: > java -jar jenkins.war
- Open your browser and point it to http://localhost:8080/
To be completely honest, these steps will only run Jenkins instance and as soon as you kill the process, or shut down your computer, Hudson will go down. To finish the installation of Jenkinbs you need to install it as a service on your host machine. The instructions for that vary by platform, but under Windows it is just as simple as following links from dashboard:
- From Dashboard: Manage Hudson → Install as Windows Service
- Enter path to Jenkins service home (e.g. C:\Build\Jenkins)
- Press Install button
Wait until Jenkins installs itself as a Window service - Press "Yes" to stop currently running Jenkins instance and start the windows service.
Conclusion
Installing both was relatively easy process.- With TeamCity you get nice rouunded up installer package which handles all the gritty details of setting up app server, deploying applications and wrapping it up into a system service. Just download, run the installer, answer to some fairly simple questions and you'r ready to go.
- With Jenkins the process was even simpler, albeit a bit technical, requiring you to go into the command prompt to run the server.
Additionally - installing it as Windows service just blew me away - Like it? Take it - Click, click, clickedy-click and Done!
Definitely, Jenkins feels much friendlier towards "just trying it out" and it can not be bad to the developer community - using Hudson, it is not entirely impossible to have each developer running their own Hudson CI instance on their own machine - it is just so simple to set up!
What's more, since it is so easy to set up (and you don't have to commit to it by installing it as a service), it has a real advantage of being the CI of choice for every developer. Every one can run their own Jenkins instance on their computer. And that is good...
What's next
As I started to write this article, broke it up into some chapters and wrote few of them, I realized that this one has a fair chance of becoming a monster article, so I decided to brake it up by topics.This one established some background and covered installation of the server.
In the next post of the series I'll be covering post-install setup of both products
Comments