configuration-as-code-plugin VS jenkins-bootstrap-shared

First, developers could be taking care of maintaining the CI/CD tool.. As is (dev)ops will provide a running instance and everything from there is dev's responsibility, eg. Jenkins via https://plugins.jenkins.io/configuration-as-code/ .

configuration-as-code https://plugins.jenkins.io/configuration-as-code/

Now we are going to use Configuration as Code plugin and some other plugins.

Looks like it does pretty much everything except install plugins ("We don't support installing plugins with JCasC" https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/README.md)

--- jenkins: numExecutors: 1 systemMessage: "Hi, jenkins setup with jcasc" securityRealm: local: allowsSignup: false # prevents anonymous users from creating an account through the web interface users: - id: ${JENKINS_ADMIN_ID} password: ${JENKINS_ADMIN_PASSWORD} authorizationStrategy: globalMatrix: permissions: #- "View/Delete:authenticated" #- "View/Read:authenticated" #- "View/Configure:authenticated" #- "View/Create:authenticated" - "Job/Read:authenticated" - "Job/Build:authenticated" - "Job/Configure:authenticated" - "Job/Create:authenticated" - "Job/Delete:authenticated" - "Job/Discover:authenticated" - "Job/Move:authenticated" - "Job/Workspace:authenticated" - "Job/Cancel:authenticated" - "Run/Delete:authenticated" - "Run/Replay:authenticated" - "Run/Update:authenticated" - "Overall/Read:admin" - "Overall/Administer:admin" crumbIssuer: "standard" # Docker: https://github.com/jenkinsci/configuration-as-code-plugin/tree/master/demos/docker clouds: - docker: name: "docker" dockerApi: dockerHost: uri: "unix:///var/run/docker.sock" templates: - labelString: "docker-agent" dockerTemplateBase: # TODO: pin sha256 or versions when using in production image: "jenkins/agent" remoteFs: "/home/jenkins/agent" connector: attach: user: "jenkins" instanceCapStr: "10" retentionStrategy: idleMinutes: 1 security: scriptApproval: approvedSignatures: - method java.lang.String indexOf int - method io.jenkins.plugins.casc.ConfigurationAsCode configure - staticMethod io.jenkins.plugins.casc.ConfigurationAsCode get tool: git: installations: - home: "git" name: "Default" jdk: installations: - home: "/opt/java/openjdk" name: "java" maven: installations: - name: "maven" properties: - installSource: installers: - maven: id: "3.6.2" jobs: - file: /var/jenkins_config/jobs/folders.groovy - file: /var/jenkins_config/jobs/jobs.groovy

At my previous job the entirety of Jenkins was all in code. We would blow away our entire Jenkins instance and just copy/paste the config back into Jenkins and it would all be back. I believe that also had all of the configurations for the jobs as well. In that case, that could be ideal. If I remember correctly this was all done in Groovy and not using the Configuration as Code (YAML) plugin.

Most of the main plugins are configurable (here are some examples) and the rest you can configure via groovy. If there's good documentation, writing the groovy scripts is fairly easy too

You can capture plugins and Jenkins versions using the script console to provision a second pristine Jenkins for additional testing like upgrade testing. I go deeper into this with complete immutable Jenkins infrastructure with jenkins-bootstrap-shared.

I recommend capturing your plugin versions. You can do it via maven or gradle. You could use the script console scripts on Jenkins. For testing upgrades you would need other means.

Jenkins as immutable infra

You can do this by script console yourself and use the community docker image. Alternately, you can try out jenkins-bootstrap-shared project I made which pulls Jenkins into a JKD8 container (I plan to upgrade it to OpenJKD11 since Jenkins now supports that).

Here's how I have it scripted. (documentation : https://github.com/samrocketman/jenkins-bootstrap-shared/tree/main/scripts/upgrade )