Let’s dispel the myth about Jenkins being the gold standard continuous integration tool. I’m sorry, TeamCity is much better.
Dispelling the Jenkins CI Myth
I started using Jenkins when it was called Hudson, before the Oracle naming spat. Recently, I downloaded and installed it again and was shocked to see that little appears to have changed in so many years. What’s in a UI? Not much if you’re technical, but geeze, Jenkins still has the aura of an app knocked together during an all night hackathon in 1997 .
Let’s knock the legs from under this myth.
1. Jenkins is Open Source
Many Jenkins fans are FOSS fans. If there is an open source solution, perhaps buggy or poorly maintained, they feel compelled to use it. Much like one can imagine RMS foregoing a life saving treatment if the medical apparatus didn’t run open source code he’d compiled himself.
Be careful though as there are few absolute FOSS purists in practice. Inevitably, people use the best tool for the job at hand. Why does a company write code with 23 FOSS tools/languages on closed source Windows desktops? Probably because it works for them and that special accounting application or antiquated, but stable, engineering software that’s core to the business. Just because other options are Open Source doesn’t make the whole tool chain better in practice.
2. Jenkins is FREE!, TeamCity is Expensive
The Jenkins fan will note that Jenkins is free, but TeamCity costs money. Hiss! Boo!
They’ll not mention you can use the TeamCity CI server and three (3) build agents for FREE. And that you’re only out $100/agent thereafter and $1000 for the CI server. Anyone bought Visual Studio lately? Anyone use the many $5K/seat tools out there? Anyone…use Windows (Debian lover myself) ? They all cost a ton more than Jenkins. Why do you use those rather than the FOSS solution? Perhaps it’s for the quality of the tool or the paid support behind it. Remember, many of us work for profit.
3. We’re an OSS Project, We Can’t Afford Paid Anything
I’m a huge fan of open source projects. I contribute to several. And I frequently spar over what CI tool to use. CloudBees, BuildHive, Travis or your own Jenkins Instance? Fatuously such groups write off TeamCity since it would cost cheddar they don’t have. But that would completely ignore the fact that JetBrains gives away everything for FREE to open source projects.
4. But There’s a Plugin For That!
My first production encounter with Jenkins was a comedy of errors. I had inherited a mature Jenkins installation where all quotidian tasks were either manual or cumbersome. For example, hand written jobs to do nothing but free up space from other jobs. Hacks and hacks and duct tape scripts to make the build chains we used. And throw in a bi-weekly inopportune crash for good measure.
I was shocked. Everything folks had wasted their time on via various scripts and manual efforts was a standard, default, out of the box feature in TeamCity. But stand back if you ask a Jenkins fan about this. They will counter “but there’s a plugin for that!” Perhaps there is. A non-code reviewed plugin that does part of what you want and was last updated 19 months ago and a few major releases hence. Or, there will be three plugins to do almost the same task, and most of it might work, but check the GitHub page and recompile if you want that functionality.
This is sad given that the configurations TC has out of the box could have skipped $10K in developer efforts over the last two years. But, alas, TC isn’t FREE.
Other Bones to Pick
Some other things that Jenkins could improve:
- NO SECURITY by default? Why? TC secures out of the box. Common man.
- No Password masking by default, you’ll need the masking plugin
- No PreTested Commit – a TC standard that’s integrated with Intellij/Eclipse – Jenkins progress
- Defaults to port
8080… way too common a port for DEV’s. Will conflict with all Java devs - Startup logs are to
.err.log? Why? - Lack of timestamps in 2 of 3 logs. You didn’t want to know when that error happened.
- Plugin install still triggers server restart, even if no plugins were updated/installed
- Coarseness of “Auto-Refresh” – keeps reloading documentation pages! Is it 1998? XHR much?
Conclusions and Disclaimers
Give TeamCity a try. I’ve been loving it for 4 6 years now and use it on every project. Do I work for JetBrains? Nope. Then why write this? Because everyone I talk to claims Jenkins is God’s gift to integration. It makes me think I’m must be taking crazy pills, so I’ve written this so someone out there can make a more informed CI tooling decision.
Don’t Take My Word For It
For all your know I’m a shill that screams at fire hydrants in the night. Read the top hits for “TeamCity vs Jenkins” and you’ll discover the same thesis.