Jenkins as Code

Everything you've configured by clicking through the Jenkins UI lives in a black box. If the server dies, that configuration is gone. Jenkins as Code means treating your pipelines, job definitions, and shared logic the same way you treat application code — versioned, reviewed, reproducible.

Jenkins as Code is not a single feature or plugin. It's a philosophy — the idea that nothing important about your CI/CD system should exist only in a UI form that can't be versioned, diffed, or recovered. This lesson covers the three layers of that philosophy: pipeline as code (Jenkinsfiles), job generation as code (Job DSL), and shared pipeline logic as code (shared libraries).

The Three Layers of Jenkins as Code

Layer 1 — Pipeline as Code in Depth

You've written Jenkinsfiles throughout this course. This section focuses on the practices that make pipeline-as-code work properly in a team — not just the syntax.

Layer 2 — Job DSL: Generating Jobs Programmatically

Multibranch Pipelines handle the per-branch job creation automatically. But for teams managing many services, folders, and views, the Job DSL plugin lets you generate the entire job structure from a script — no clicking required.

The scenario:

You're a platform engineer at a company with 15 microservices, each needing a Multibranch Pipeline job inside a team folder. You've been creating these manually. A new team is onboarding next Monday with 5 new services. You need a script that generates all jobs from a list — run it once and everything appears in Jenkins, correctly configured.

New terms in this code:

• Job DSL plugin — a Jenkins plugin that provides a Groovy-based DSL (Domain Specific Language) for defining jobs. A seed job runs the DSL script and creates or updates all the jobs it defines.
• seed job — a regular Jenkins Pipeline job whose only purpose is to run the Job DSL script. When you need to add or change jobs, update the DSL script and re-run the seed job.
• multibranchPipelineJob() — a Job DSL method that creates a Multibranch Pipeline job. Takes the job path (including folder) as its argument.
• branchSources { github() } — configures the branch source for the Multibranch Pipeline. Tells Jenkins which GitHub repo to scan for branches.
• folder() — a Job DSL method that creates a Jenkins folder. Creates it if it doesn't exist, leaves it untouched if it does.

// jobs/seed.groovy — the Job DSL script
// This file lives in a Git repository and is run by a Jenkins seed job
// Running this script creates or updates all the jobs it defines

// Define all services and their team owners
// Adding a new service = adding one line to this list
def services = [
    [team: 'payments',  repo: 'checkout-service'],
    [team: 'payments',  repo: 'payment-api'],
    [team: 'payments',  repo: 'fraud-detection'],
    [team: 'frontend',  repo: 'web-app'],
    [team: 'frontend',  repo: 'mobile-app'],
    [team: 'platform',  repo: 'api-gateway'],
    [team: 'platform',  repo: 'auth-service'],
]

// Get unique team names to create folders
def teams = services.collect { it.team }.unique()

// Create a folder for each team
teams.each { teamName ->
    folder(teamName) {
        description("Jobs for the ${teamName} team")
        // Folder-level properties — e.g. views, health metrics
        properties {
            // Restrict who can see this folder (uses Project-based matrix auth)
            authorizationMatrix {
                inheritanceStrategy { nonInheriting() }
                entries {
                    user {
                        name("admin")
                        permissions(["hudson.model.Hudson.Administer"])
                    }
                }
            }
        }
    }
}

// Create a Multibranch Pipeline job for each service inside its team folder
services.each { service ->
    def jobPath = "${service.team}/${service.repo}"

    multibranchPipelineJob(jobPath) {
        description("CI/CD pipeline for ${service.repo}")

        // Where to find branches — GitHub in this case
        branchSources {
            github {
                id("${service.repo}-source")
                repoOwner("acmecorp")
                repository(service.repo)
                // Use a stored Jenkins credential for GitHub API access
                credentialsId("github-token")
                // Discover branches, PRs, and tags
                traits {
                    gitHubBranchDiscovery { strategyId(1) }
                    gitHubPullRequestDiscovery { strategyId(2) }
                }
            }
        }

        // How often to scan for new branches
        triggers {
            periodic(5)  // scan every 5 minutes
        }

        // Orphaned branch strategy — clean up deleted branches after 7 days
        orphanedItemStrategy {
            discardOldItems {
                daysToKeep(7)
                numToKeep(10)
            }
        }
    }
    println "Created job: ${jobPath}"
}

Processing DSL script jobs/seed.groovy
Creating folder: payments
Creating folder: frontend
Creating folder: platform
Created job: payments/checkout-service
Created job: payments/payment-api
Created job: payments/fraud-detection
Created job: frontend/web-app
Created job: frontend/mobile-app
Created job: platform/api-gateway
Created job: platform/auth-service

Triggering branch scans for all Multibranch pipelines...
payments/checkout-service: scanning... found 4 branches
payments/payment-api: scanning... found 2 branches
payments/fraud-detection: scanning... found 3 branches
frontend/web-app: scanning... found 6 branches
frontend/mobile-app: scanning... found 2 branches
platform/api-gateway: scanning... found 3 branches
platform/auth-service: scanning... found 5 branches

Finished: SUCCESS

Layer 3 — Shared Libraries: Reusable Pipeline Logic

The third layer is shared libraries — a Git repository of Groovy code that any Jenkinsfile in the organisation can import. This is where your standard Docker build, Kubernetes deploy, Slack notification, and security scan logic lives.

// Jenkinsfile in checkout-service — using the shared library
// Everything team-specific is expressed here
// Everything standard is in the library
@Library('acme-pipelines@v2.1.0') _

pipeline {
    agent { label 'linux && docker' }

    options {
        timeout(time: 30, unit: 'MINUTES')
        buildDiscarder(logRotator(numToKeepStr: '20'))
    }

    stages {
        stage('Checkout') { steps { checkout scm } }
        stage('Test')     { steps { sh './gradlew test' }
                            post  { always { junit 'build/test-results/**/*.xml' } } }
        stage('Build')    { when { branch 'main' }
                            steps { buildDockerImage(appName: 'checkout-service') } }
        stage('Deploy')   { when { branch 'main' }
                            steps { deployToKubernetes(app: 'checkout-service', namespace: 'staging') } }
    }

    post {
        always  { notifySlack(appName: 'checkout-service') }
        always  { cleanWs() }
    }
}

How the Three Layers Fit Together

Practice Questions

Quiz