Jenkins Advanced Tutorial — Next Steps Exercises

4 minute read

Practice Exercises — Next Steps

These exercises test your understanding of the CI/CD landscape beyond Jenkins.

Exercise 1 — Jenkins X Evaluation

Task: List three scenarios where Jenkins X would be a better choice than traditional Jenkins, and three scenarios where traditional Jenkins would be better. Justify each with a specific technical reason.

Show Solution

Jenkins X is better when:

  1. All workloads run on Kubernetes — Jenkins X is built for K8s and automatically creates preview environments per PR using namespaces. Traditional Jenkins requires manual Kubernetes plugin configuration.

  2. You want GitOps-native promotions — Jenkins X uses environment repositories (staging, production) with automatic PRs for promotion. Jenkins requires custom scripts or additional tools like ArgoCD.

  3. You want zero CI/CD server maintenance — Jenkins X runs as distributed microservices on K8s. Traditional Jenkins requires JVM tuning, plugin updates, and controller health monitoring.

Traditional Jenkins is better when:

  1. You depend on 10+ Jenkins plugins — The 1,800+ plugin ecosystem has no equivalent in Jenkins X. Custom notification, reporting, and integration plugins cannot be migrated.

  2. Your infrastructure is mixed (VMs + containers) — Jenkins agents can run on bare metal, VMs, Docker, and Kubernetes. Jenkins X requires everything on Kubernetes.

  3. You need complex approval workflows — Jenkins has mature input steps, milestone API, and role-based approval gates. Jenkins X promotions are simpler (approve PR or not).

Exercise 2 — Tekton Task Creation

Task: Write a Tekton Task that clones a Git repository, runs npm install, and executes npm test. Use two separate steps and a workspace.

Show Solution 
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: npm-test
spec:
  params:
    - name: repo-url
      type: string
    - name: revision
      type: string
      default: "main"

  workspaces:
    - name: source

  steps:
    - name: clone
      image: alpine/git:2.43.0
      script: |
        git clone $(params.repo-url) $(workspaces.source.path)/repo
        cd $(workspaces.source.path)/repo
        git checkout $(params.revision)

    - name: test
      image: node:20-alpine
      workingDir: $(workspaces.source.path)/repo
      script: |
        npm install
        npm test

Run with:

tkn task start npm-test \
  --param repo-url=https://github.com/org/node-app.git \
  --workspace name=source,emptyDir="" \
  --showlog

Exercise 3 — GitHub Actions Equivalent

Task: Convert the following Jenkinsfile into a GitHub Actions workflow:

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test'
            }
        }
        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                sh 'mvn deploy'
            }
        }
    }
}
Show Solution 
name: CI/CD Pipeline

on:
  push:
    branches: ['**']
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
          cache: 'maven'

      - name: Build
        run: mvn clean package

      - name: Test
        run: mvn test

  deploy:
    needs: build
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
          cache: 'maven'

      - name: Deploy
        run: mvn deploy
        env:
          MAVEN_USERNAME: $
          MAVEN_PASSWORD: $

Key differences:

  • GitHub Actions uses YAML instead of Groovy
  • when { branch 'main' } becomes if: github.ref == 'refs/heads/main'
  • Secrets use ${{ secrets.NAME }} instead of Jenkins credentials binding
  • No persistent agent — each job gets a fresh runner

Exercise 4 — Hybrid CI/CD Design

Task: Design a hybrid CI/CD architecture where Jenkins handles CI (build + test) and ArgoCD handles CD (deployment). Draw the data flow and list what triggers each step.

Show Solution 
Data Flow:

1. Developer pushes code to GitHub
2. GitHub webhook triggers Jenkins pipeline
3. Jenkins:
   a. Clones repository
   b. Builds application
   c. Runs tests
   d. Builds Docker image
   e. Pushes image to registry (e.g., ECR)
   f. Updates image tag in GitOps repo (e.g., kustomization.yaml)
4. ArgoCD detects change in GitOps repo
5. ArgoCD syncs the new image to Kubernetes cluster

Triggers:
- Step 2: GitHub webhook → Jenkins (push event)
- Step 3f: Jenkins pipeline step → git commit to GitOps repo
- Step 4: ArgoCD polling or webhook from Git → ArgoCD sync
- Step 5: Automatic (ArgoCD auto-sync) or manual (ArgoCD manual sync)

Architecture:

┌──────┐  webhook  ┌─────────┐  push image  ┌──────────┐
│GitHub│──────────▶│ Jenkins │────────────▶│ Registry │
│      │           │ (CI)    │             │ (ECR)    │
└──────┘           └────┬────┘             └──────────┘
                        │ update tag
                        ▼
                   ┌──────────┐  sync    ┌────────────┐
                   │ GitOps   │◀────────│  ArgoCD    │
                   │ Repo     │         │  (CD)      │
                   └──────────┘         └─────┬──────┘
                                              │ deploy
                                              ▼
                                        ┌────────────┐
                                        │ Kubernetes │
                                        │ Cluster    │
                                        └────────────┘

Exercise 5 — Migration Assessment

Task: Your organisation has 50 Jenkins pipelines, 15 custom plugins, and runs on a mix of VM and Kubernetes agents. The CTO wants to migrate to GitHub Actions. Write a brief assessment (5 bullet points) on feasibility, risks, and a recommended approach.

Show Solution

Assessment:

  1. Feasibility: Moderate-High Risk — 15 custom plugins likely have no GitHub Actions equivalents. Each plugin must be evaluated individually — some may have community Actions, others will require custom Actions (TypeScript/Docker) to be written.

  2. Agent compatibility issue — VM-based agents in Jenkins cannot be directly replicated. GitHub self-hosted runners support Linux/macOS/Windows VMs, but the provisioning and tooling will differ. Budget 1–2 weeks per agent type for reconfiguration.

  3. Pipeline conversion effort — 50 Groovy Jenkinsfiles must be rewritten as YAML workflows. Estimate 2–4 hours per simple pipeline, 1–2 days per complex pipeline with shared libraries. Total: approximately 200–400 engineering hours.

  4. Vendor lock-in risk — Moving to GitHub Actions creates dependency on GitHub. If the organisation uses GitLab, Bitbucket, or self-hosted Git, this migration does not make sense. Ensure long-term commitment to GitHub.

  5. Recommended approach — Phase the migration over 3 months:

    • Month 1: Migrate 5 simple pipelines, build reusable composite Actions for common patterns
    • Month 2: Migrate 20 pipelines using the composite Actions
    • Month 3: Migrate remaining 25 pipelines, decommission Jenkins
    • Keep Jenkins running in read-only mode for 30 days after full migration

Congratulations! You have completed the Jenkins Advanced Tutorial exercises. Return to the tutorial home to review any chapter.

Updated:

You may also enjoy