Distributed Builds with Jenkins #JenkinsCI

Blue (171 Angstroms) full disk image: The Sun'...

Image via Wikipedia

My notes from a talk about Jenkins presented by Kohsuke Kawaguchi@kohsukekawa.

Jenkins is all about enabling productivity. People use Jenkins for a variety of purposes, including processing tax returns and comparing checks in order to spot forgeries. There are some amazing plugins for Android and Selenium.

Distributed builds make sense for:

  • supporting multiple environments
  • isolating jobs
  • heavy workloads

But the more machines you manage, the harder things get. 

Until you automate it with "Jenkins PXE Plugin" which manages various ISO disk images and network boots machines.

"We put alot of effort into making distributed builds simple, so it is a shame you all are not using it!"

"Treat servers like livestock rather than pets" ie do not bother naming them!

Master
  • serves HTTP requests
  • central data repository

Slaves
  • crazy light
  • assumed to be unreliable
  • easily scales to 100 nodes
  • basically a little Java app
  • all communications via SSH, even installs happen over SSH (including Java, ant, maven, etc)
  • can target jobs to different groups of slaves depending on tags
  • jobs can be sticky to make use of faster machines and minimize big checkouts
  • manage health and re-allocate servers when hardware fails
  • can kill run-away processes
  • can run a pool of AMI instances on EC2
Matrix Project
  • repeat similar tasks with slight variations
  • controls complexity without running too many builds
  • statistically covers all basis
  • considers using filters to vary the set of builds but still re-run failed builds
  • can run a 'pre-check' via filters to avoid mass failure over common/base scenario

Related articles