Alternatives to Job DSL in Jenkins CASC, or a backup plan

Jenkins Configuration as Code (CASC) Setup - Jenkins 2.462.1

  • controller: Running Java 17 in Docker (jenkins/jenkins:lts-jdk17)
  • Agents: Running Java 17 in Docker (jenkins/inbound-agent:latest)
  • Job Management: Using Job DSL for job configuration as code

At my company, we’re transitioning to a fully configured-as-code Jenkins setup, and on managing job configurations as code.

Currently, about 30% of our jobs use Jenkinsfiles, with the rest being freestyle jobs. Even for pipeline jobs, the configuration still needs to be handled through the UI.

In our experimental Jenkins CASC setup, we’re using the Job DSL plugin to create seed jobs and move configuration from the UI to Groovy scripts. This approach is working well for us.

We also experimented with using the Organization Folder to scan for Jenkinsfiles, but many of our jobs have configuration that Jenkinsfiles alone can’t handle. This made the approach less viable for us—unless pipelines can somehow include all necessary configurations?

My main worry, and the reason for this post, is that I see that the Job DSL is up for adoption and for both the solutions I mentioned, and especially the former, we would rely highly on it.

I’m looking for insights from anyone who has used Jenkins CASC in production. Are there more robust alternatives to the Job DSL plugin, or potential backup strategies we should consider?

Thanks in advance for your help!