Over the past few months my team had put a lot of time & effort into taking the configuration of all of those pre-existing, manually created jobs and codifying them via the Jenkins Job DSL Plugin. This week all of that hidden “plumbing” work finally paid its first dividends for us when we had to cut the branch for our upcoming release, and the benefit was enormous. Since the Job DSL Plugin puts all of our configuration into source control and gives us the ability to programmatically create all of our Jenkins jobs, it saved us many painful hours of manual job configuration via the Jenkins UI. Instead of having to copy each of those existing 50 jobs and modify them by hand, we only had to do some editing of our Groovy files, send for review, submit the changes to our Git repo, and watch the new jobs get created automatically.
Given that this was our first time doing this type of release branching we had to work out a few kinks and do extra validation, but by 5pm we had all of the continuous builds working for each repo as well as images for our product being successfully created.
Even better is that as we were working out a few obscure kinks with the developers, those developers quickly realized that they too could edit the Groovy files in Git to make simple changes to the job configuration. In other words, the developers realized that they were not gated upon our DevOps team to make job configuration changes for them. I’m hoping that we can expand on this in the coming weeks and have the developers take even more ownership of the build job configurations.
The big benefit with the Job DSL Plugin is that it takes job configuration that was previously done by hand in a UI and puts it into a documented format in source control where the changes can be reviewed via Review Board and tracked over time. With that we can confidently provide access to making job configuration changes to the whole development team which ultimately makes for a quicker configuration change process and a lighter workload for my team.