Workflows — The Factory Daily Routine

The factory owner has the assembly line set up. Now they need a routine — a shared way of working that turns every code change into a tested, built, and deployed artifact without manual coordination.

The CI/CD Pipeline

The pipeline has two halves:

1. CI (Continuous Integration) — Build + Test. Happens on every push. Fast, automated.
2. CD (Continuous Delivery/Deployment) — Package + Deploy. Happens after CI succeeds. May include manual approval.

Remember

CI catches bugs early (every push is tested). CD delivers value fast (every merge is deployed). Together, they eliminate "it works on my machine."

GitHub/GitLab Integration — The Order Button

Webhook (Recommended)

Configure a webhook in your Git provider to notify Jenkins on every push:

1. Go to your repo Settings → Webhooks
2. Add URL: https://your-jenkins-url/github-webhook/
3. Select "Just the push event"

In the Jenkinsfile — trigger on push

triggers {
    githubPush()
}

Polling (Fallback)

Check Git every 5 minutes

triggers {
    pollSCM('H/5 * * * *')
}

Remember

Webhooks are instant. Polling has a delay. Always prefer webhooks.

Branch-Based Pipelines — Different Assembly Lines

Run different stages based on the branch:

Branch-based pipeline

pipeline {
    agent { docker { image 'node:20-alpine' } }

    stages {
        stage('Build') {
            steps { sh 'npm ci && npm run build' }
        }

        stage('Test') {
            steps { sh 'npm test' }
        }

        stage('Deploy to Staging') {
            when { branch 'develop' }
            steps {
                sh 'kubectl apply -f k8s/staging/'
            }
        }

        stage('Deploy to Production') {
            when { branch 'main' }
            input { message 'Deploy to production?' }
            steps {
                sh 'kubectl apply -f k8s/production/'
            }
        }
    }
}

Branch	What happens
Feature branches	Build + Test only
develop	Build + Test + Deploy to staging
main	Build + Test + Deploy to production (with approval)

Remember

Feature branches should never deploy to production. Only main should trigger production deployments.

Artifact Management — The Warehouse

Jenkins can store build artifacts (JARs, Docker images, reports):

Archive test reports

post {
    always {
        junit 'test-results/**/*.xml'
        archiveArtifacts artifacts: 'dist/**', fingerprint: true
    }
}

Publish test results

stage('Test') {
    steps {
        sh 'npm test -- --reporter junit'
    }
    post {
        always {
            junit 'test-results/*.xml'
        }
    }
}

Remember

Archiving artifacts makes them downloadable from the Jenkins UI. This is useful for debugging failed builds.

Notification — The Factory Bell

Slack notification

post {
    success {
        slackSend(
            color: 'good',
            message: "Build ${env.BUILD_NUMBER} succeeded for ${env.JOB_NAME}"
        )
    }
    failure {
        slackSend(
            color: 'danger',
            message: "Build ${env.BUILD_NUMBER} failed for ${env.JOB_NAME}"
        )
    }
}

Email notification

post {
    failure {
        mail to: 'team@campuslibrary.dev',
             subject: "Build ${env.BUILD_NUMBER} failed",
             body: "Check: ${env.BUILD_URL}"
    }
}

Remember

Notify on failure only. Success is the default expectation — no need to send a message for every green build.

Multi-Branch Pipelines — One Job, All Branches

Jenkins can automatically create a pipeline for every branch in your repo:

1. Create a "Multibranch Pipeline" job
2. Point it to your Git repo
3. Jenkins scans all branches and creates a pipeline for each one that has a Jenkinsfile

Remember

Multi-branch pipelines are the "automatic assembly line installer." Every new branch gets its own pipeline without manual configuration.

Credentials Management — The Safe

Store credentials in Jenkins (not in Git):

1. Go to Jenkins → Manage Jenkins → Credentials
2. Add credentials (username/password, SSH key, secret file)
3. Reference them in the Jenkinsfile with withCredentials

Multiple credential types

withCredentials([
    usernamePassword(credentialsId: 'dockerhub', usernameVariable: 'DOCKER_USER', passwordVariable: 'DOCKER_PASS'),
    string(credentialsId: 'slack-webhook', variable: 'SLACK_URL')
]) {
    sh 'docker login -u $DOCKER_USER -p $DOCKER_PASS'
    sh "curl -X POST -H 'Content-type: application/json' --data '{\"text\":\"Deployed!\"}' $SLACK_URL"
}

Common mistake

Never commit credentials to Git. Use Jenkins credentials store and reference by ID.