Build Management with Headless Jenkins

At this point we have completed the artifact storage and source control management components. The final part is setting up a build process. The Jenkins setup described here is slightly different from a typical Jenkins installation. Generally Jenkins is setup as an "always-on" process, typically consisting of a master installation with ephemeral build agents. When referring to "always-on" we are talking about the fact that once installed, it will be left running and then used to create and schedule a variety of jobs.

However, for our purpose, we treat jenkins as a single, one-time process with the sole purpose of only executing a job once. We also refer to this as Headless Jenkins as we have no need to ever use the User interface to execute jobs. Consider the following job run flow:

  1. Detect a source change in Repository
  2. Schedule new Jenkins Docker process
  3. Automatically install and configure Jenkins Application
  4. Automatically configure and run Job
  5. Publish Job Results
  6. Destroy Jenkins Docker process

Besides a cleaner and per-Job-as-Code Jenkins setup, not using the master has benefits of availability. If you run a typical master/agent infrastructure, anytime your master is down, needs to be updated, or has issues, none of your jobs will run.

For the Jenkins installation we will be doing the following:

  1. Base Install - a minimally configured Jenkins instance used as a template for other Jenkins Job Runners
  2. Test Project - a java spring boot microservice based test setup to be used as example for Jenkins and Jenkinsfile pipeline executions
  3. Headless Install - a Jenkins pipeline based job runner
  4. Headless Install Docker Builds - another Jenkins pipeline based job runner for Docker builds