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:
- Detect a source change in Repository
- Schedule new Jenkins Docker process
- Automatically install and configure Jenkins Application
- Automatically configure and run Job
- Publish Job Results
- 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:
- Base Install - a minimally configured Jenkins instance used as a template for other Jenkins Job Runners
- Test Project - a java spring boot microservice based test setup to be used as example for Jenkins and Jenkinsfile pipeline executions
- Headless Install - a Jenkins pipeline based job runner
- Headless Install Docker Builds - another Jenkins pipeline based job runner for Docker builds