Belajar Jenkins - Advanced Flow Control (Parallel, Matrix & Conditionals)

#Pendahuluan

Di episode 6 sebelumnya kita membangun pipeline yang interaktif dengan parameter dan gerbang persetujuan manual. Tapi ada satu kelemahan besar yang belum kita sentuh: semua stage di pipeline kita masih berjalan berurutan. Stage test tidak dimulai sebelum stage build selesai, stage deploy menunggu test selesai. Kalau satu build memakan waktu satu jam, dan kebanyakan waktu itu sebenarnya bisa dijalankan bersamaan, kita sedang membuang setengahnya.

Bayangkan sebuah dapur restoran yang hanya punya satu koki: dia memasak appetizer, lalu menunggu, lalu memasak main course, lalu dessert — sementara oven, kompor, dan blender menganggur. Dapur yang efisien menjalankan beberapa hidangan sekaligus dengan koki berbeda. Itulah yang episode ini lakukan untuk Jenkins: eksekusi paralel, matrix strategy untuk menguji banyak kombinasi environment sekaligus, eksekusi kondisional agar stage hanya jalan ketika diperlukan, dan post-execution actions untuk menangani semua kemungkinan hasil build dengan rapi.

#Pembahasan Utama

#Eksekusi Paralel dengan parallel

Blok parallel menjalankan beberapa stage secara bersamaan, masing-masing pada executor terpisah. Ini cara paling mudah memangkas total durasi pipeline: tiga stage test yang masing-masing 5 menit menjadi 5 menit total, bukan 15 menit.

Stage paralel untuk testing

stage('Testing Paralel') {
    failFast true
    parallel {
        stage('Unit Test') {
            steps {
                sh 'npm run test:unit'
            }
        }
        stage('Integration Test') {
            steps {
                sh 'npm run test:integration'
            }
        }
        stage('Lint & Typecheck') {
            steps {
                sh 'npm run lint'
            }
        }
    }
}

Beberapa aturan penting:

• failFast true membatalkan branch paralel lainnya begitu satu branch gagal. Tanpa ini, branch lain tetap berjalan sampai selesai — kadang diinginkan (kumpulkan semua kegagalan), kadang boros. Pilih sesuai kebutuhan.
• Setiap branch paralel mendapat salinan workspace sendiri. Perubahan file di satu branch tidak terlihat di branch lain — desain pipeline yang bergantung pada urutan modifikasi file tidak aman di sini.
• Jika agent tersedia, branch bisa diarahkan ke label berbeda dengan menambahkan agent di dalam masing-masing stage, sehingga unit test dan integration test berjalan di mesin terpisah.

#Matrix Strategy untuk Multi-Environment Build

Blok matrix menjalankan stage yang sama untuk setiap kombinasi dari axes yang kalian definisikan. Contoh paling klasik: aplikasi Node.js yang harus lolos di beberapa versi Node sekaligus beberapa OS. Tanpa matrix, kalian menulis stage build yang sama berkali-kali dengan nilai berbeda; dengan matrix, satu definisi stage dijalankan untuk semua kombinasi.

Matrix strategy Node & OS

matrix {
    axes {
        axis {
            name 'NODE_VER'
            values '18', '20'
        }
        axis {
            name 'OS'
            values 'linux', 'windows'
        }
    }
    excludes {
        exclude {
            axis {
                name 'OS'
                values 'windows'
            }
            axis {
                name 'NODE_VER'
                values '18'
            }
        }
    }
    stages {
        stage('Install & Build') {
            steps {
                echo "Node ${NODE_VER} di ${OS}"
                sh 'npm ci'
                sh 'npm run build'
            }
        }
    }
}

Cara membacanya: empat kombinasi akan dijalankan — Node 18 di linux, Node 18 di windows, Node 20 di linux, Node 20 di windows. Blok excludes menghapus kombinasi yang tidak diinginkan (misalnya tim tidak memelihara support Node 18 di windows), sehingga hanya tiga kombinasi yang benar-benar dieksekusi. Nilai tiap axis diakses sebagai variabel bernama sama dengan axis — NODE_VER dan OS — seperti yang diinterpolasikan pada baris echo di dalam blok kode.

#Eksekusi Kondisional dengan when

Stage tidak harus selalu jalan. Blok when membuat stage bersyarat: hanya dieksekusi jika kondisinya terpenuhi. Inilah yang membuat satu Jenkinsfile bisa melayani banyak alur — dev, staging, dan production tanpa menulis ulang.

Kondisi yang paling sering dipakai:

when { branch 'main' } membatasi deploy hanya pada branch utama. Gabungan beberapa kondisi di satu blok when bersifat AND — semuanya harus terpenuhi:

Kondisi gabungan

stage('Build Java') {
    when {
        changeset '**/*.java'
    }
    steps {
        sh 'mvn -q package'
    }
}
 
stage('Deploy') {
    when {
        branch 'main'
        expression { return params.DEPLOY }
    }
    steps {
        echo 'Deploying ke production'
    }
}

when { changeset '**/*.java' } adalah optimasi besar: stage build Java hanya berjalan jika ada file Java yang berubah di commit ini. Commit yang hanya menyentuh README tidak memicu kompilasi Java yang lambat. Perhatikan expression { return params.DEPLOY } yang membaca boolean parameter dari episode 6 — kombinasi parameter dan when menghasilkan pipeline yang sangat fleksibel.

#Post-Execution Actions dengan post

Setelah seluruh stage selesai, blok post menentukan apa yang terjadi berdasarkan hasil akhir. Ini tempat yang tepat untuk mengumpulkan laporan test, mengirim notifikasi, atau membersihkan workspace — bukan di tengah stage. Kondisi yang paling umum:

• always dijalankan apa pun hasilnya — cocok untuk publikasi laporan test lewat junit.
• success dan failure untuk aksi spesifik hasil, seperti notifikasi.
• unstable saat test ada yang gagal tapi build tidak crash.
• aborted saat build dibatalkan user atau timeout.
• cleanup istimewa: selalu dijalankan di akhir — bahkan saat build dihentikan di tengah atau gagal sebelum stage selesai. Tempat paling aman membersihkan workspace.

Penerapan lengkapnya bisa kalian lihat di contoh pipeline bawah: post mempublikasikan laporan test, menandai kegagalan, dan membersihkan workspace setiap build.

#Contoh Pipeline Lengkap

Semua konsep digabung: test paralel, build kondisional, deploy bersyarat, dan post yang membersihkan diri:

Pipeline paralel + kondisional + post

pipeline {
    agent any
 
    parameters {
        booleanParam(name: 'DEPLOY', defaultValue: false, description: 'Jalankan deploy?')
    }
 
    stages {
        stage('Testing') {
            failFast true
            parallel {
                stage('Unit Test') {
                    steps { sh 'npm run test:unit' }
                }
                stage('Lint') {
                    steps { sh 'npm run lint' }
                }
            }
        }
 
        stage('Build Package') {
            when {
                changeset 'src/**'
            }
            steps {
                sh 'npm run build'
            }
        }
 
        stage('Deploy Production') {
            when {
                branch 'main'
                expression { return params.DEPLOY }
            }
            steps {
                echo 'Deploy ke production'
            }
        }
    }
 
    post {
        always {
            junit 'reports/**/*.xml'
        }
        failure {
            echo 'Ada stage yang gagal'
        }
        cleanup {
            cleanWs()
        }
    }
}

Perhatikan pola alurnya: test berjalan paralel dan cepat, build hanya dipicu jika kode sumber berubah, deploy production hanya dari branch main dan hanya jika manusia mencentang parameter DEPLOY. Pipeline yang sama melayani developer (commit biasa, tanpa deploy) dan production (terkontrol) — tanpa duplikasi Jenkinsfile.

#Penutup

Pada episode 7 ini kita membedah empat alat kendali alur yang mengubah pipeline linear menjadi pipeline yang cepat dan cerdas: parallel untuk menjalankan stage testing bersamaan dengan failFast, matrix dengan axes dan excludes untuk menguji banyak kombinasi environment dari satu definisi, when untuk eksekusi kondisional berdasarkan branch, expression, dan changeset, serta post untuk aksi pasca-build seperti publikasi laporan, notifikasi, dan pembersihan.

Inti yang harus kalian bawa:

• parallel memangkas durasi build; ingat setiap branch punya salinan workspace sendiri.
• matrix menjalankan stage untuk setiap kombinasi axes; excludes membuang kombinasi yang tidak diinginkan.
• when membuat stage bersyarat; gabungan kondisi di satu blok bersifat AND.
• when { changeset '...' } hanya membangun yang benar-benar berubah — hemat waktu build besar-besaran.
• post { cleanup } selalu dijalankan terakhir, bahkan saat build gagal atau dihentikan.

Pipeline kalian sekarang cepat dan adaptif. Di episode 8 berikutnya kita masuk ke topik yang sangat ditunggu: integrasi Docker di dalam Jenkins pipeline — menjalankan seluruh build di dalam container, membangun image Docker dari pipeline, dan mendorongnya ke registry secara aman. Sampai jumpa di episode 8!