Over the last few years, it’s amazing how much we’ve grown to rely on Jenkins for our continuous integration server needs. This week’s Rebelcast is about how we use Jenkins, what our installation looks like, and some of the things we’ve learned over the years with CI.
Our Jenkins Configuration and Usage
We’ve been using Jenkins for the last 4 years and now we’ve got 300 jobs configured, running 27,000 builds a week.
We run a bare-metal Jenkins cluster at ZeroTurnaround namely because the type of software we make (i.e. JRebel & LiveRebel) require a lot of I/O operations for testing.
We also find bare-metal machines–which we got from the neighborhood shop for cheap (they still include the CD-ROM drive because it’s more expensive to remove it)–with SSDs and lots of RAM are better for quickly spinning up images and maintaining our large test suite.
The ZT team set up with Jenkins
It’s important to have a single person in charge of running your Jenkins cluster. We took the liberty of naming our Jenkins servers after Starcraft units, so our Jenkins Cluster Owner can quickly communicate with his minions, who we call Jenkins Overlords. In addition, each team in our engineering department has one member responsible for alerting the Jenkins Overlords to problems.
If you Continuous Integration server, be it Jenkins, Bamboo, TeamCity or Travis CI, is not a mission-critical element of your engineering infrastructure, it will be soon. Other plugins we mention in this post on Jenkins pipelines could also be of interest to you.
Have a single, clear owner of your Jenkins installation who will only look after that. Then when you crash because you tried to release two new product versions at the same time, only one person is freaking out ;-)
If you’re a smaller shop, then don’t get blown away by all the buzz about Cloud and keep bare metal machines an option–when we looked into it, cloud solutions would end up costing us 50%+ more than hardware. And use tagging when you can!