Belajar Jenkins - Parameterized Pipelines & Manual Approval Gates

#Pendahuluan

Di episode 5 sebelumnya kita membedah variables, environment, dan secret management — sekarang pipeline kalian bisa membaca konfigurasi dan credentials dengan aman tanpa menyimpan rahasia di kode. Tapi ada satu pertanyaan besar sebelum pipeline layak menyentuh produksi: apakah otomatisasi penuh selalu aman?

Bayangkan ini. Tim kalian membangun autopilot yang bisa mendaratkan pesawat sendiri tanpa pilot. Teknisnya mungkin berhasil, tapi siapa yang bertanggung jawab saat roda pendaratan gagal di tengah badai? Di dunia CI/CD, mendeploy otomatis ke production setiap kali ada commit tanpa persetujuan manusia adalah versi autopilot tanpa pilot itu. Prosedur keselamatan penerbangan memakai two-man rule: dua orang harus memverifikasi sebelum tindakan kritis dilakukan.

Di episode ini kita membuat pipeline yang interaktif: parameterized pipeline yang menerima input dari user lewat form sebelum build dijalankan, dan manual approval gate menggunakan step input yang menjeda pipeline dan menunggu persetujuan dari orang berwenang — ditambah timeout handling agar pipeline yang menganggur tidak menyumbat sistem selamanya.

#Pembahasan Utama

#Konsep Parameterized Pipeline

Parameterized pipeline mengubah Jenkinsfile statis menjadi formulir yang bisa diisi sebelum build berjalan. Setiap kali kalian klik tombol Build with Parameters di halaman job, Jenkins menampilkan form yang isinya kalian definisikan sendiri. Nilai yang diisi kemudian bisa diakses di seluruh pipeline lewat objek params.

Analoginya seperti memesan kopi di kedai: tanpa parameter, barista selalu membuat menu yang sama persis untuk semua orang; dengan parameter, kalian memilih ukuran, temperatur, dan gula. Satu recipe, banyak variasi — tanpa menulis satu pipeline untuk tiap variasi.

Empat tipe parameter yang paling sering dipakai:

Aturan praktis: string untuk nilai yang bebas dan sering berubah, choice untuk nilai yang harus konsisten dengan daftar yang disepakati tim, booleanParam untuk saklar, dan password hanya untuk nilai rahasia sekali pakai yang diisi operator.

#Mendefinisikan Parameter di Jenkinsfile

Parameter dideklarasikan di dalam blok parameters tepat di bawah agent:

Blok parameters

pipeline {
    agent any
 
    parameters {
        string(name: 'APP_VERSION', defaultValue: '1.0.0', description: 'Versi aplikasi')
        choice(name: 'ENVIRONMENT', choices: ['staging', 'production'], description: 'Target environment')
        booleanParam(name: 'RUN_TESTS', defaultValue: true, description: 'Jalankan test suite')
        password(name: 'DEPLOY_TOKEN', defaultValue: '', description: 'Token deployment')
    }
 
    stages {
        stage('Build') {
            steps {
                echo "Membangun versi ${params.APP_VERSION} untuk ${params.ENVIRONMENT}"
            }
        }
    }
}

Saat build pertama kali dijalankan tanpa klik Build with Parameters, Jenkins memakai nilai defaultValue. Ini penting: desain parameter dengan default yang aman dan tidak merusak, karena default inilah yang dipakai saat trigger otomatis (webhook, cron) memicu build tanpa manusia mengisi form.

#Mengakses Nilai Parameter

Nilai parameter diakses lewat objek params. Dua cara yang sering membingungkan pemula: params.X mengakses parameter dengan nama X, sedangkan variabel X saja (tanpa prefix params) juga otomatis tersedia sebagai environment variable. Referensi yang paling eksplisit adalah params.X:

• params.APP_VERSION mengembalikan nilai string yang diisi user.
• params.RUN_TESTS mengembalikan true atau false untuk boolean.
• params.ENVIRONMENT mengembalikan pilihan yang terpilih dari daftar choice.

#Manual Approval Gate dengan Step input

Ini jantung episode ini. Step input menjeda eksekusi pipeline dan menampilkan prompt di UI Jenkins yang menunggu klik Proceed atau Abort dari user yang berwenang. Pipeline tetap "hidup" tapi tidak melanjutkan ke stage berikutnya sampai ada keputusan:

Manual approval gate

stage('Persetujuan') {
    steps {
        timeout(time: 15, unit: 'MINUTES') {
            input message: 'Deploy ke Production?', ok: 'Ya, lanjutkan', submitter: 'admin-user'
        }
    }
}

Parameter yang paling penting:

• message — teks yang ditampilkan ke pemberi persetujuan, harus jelas menyebutkan apa yang akan terjadi.
• submitter — daftar username (atau nama grup) yang berhak menyetujui, dipisahkan koma. Kosongkan jika semua user boleh.
• ok — label tombol Proceed, berguna untuk konteks seperti "Ya, deploy ke production".

Mengapa meletakkan input di stage tersendiri, bukan menyelipkannya di tengah step lain? Karena stage ini terlihat jelas di Stage View pipeline, mudah diaudit, dan terpisah dari logika teknis. Orang yang menyetujui tidak perlu memahami detail build — dia hanya melihat gerbang hijau bertuliskan "Deploy ke Production?".

#Timeout Handling

Tanpa batas waktu, pipeline yang menunggu persetujuan bisa menggantung selamanya — memblokir executor, menumpuk antrian, dan membuat tim lupa ada build yang tertunda. Dua level timeout yang harus dipahami:

Timeout di level pipeline

pipeline {
    agent any
 
    options {
        timeout(time: 1, unit: 'HOURS')
        buildDiscarder(logRotator(numToKeepStr: '10'))
    }
 
    stages {
        stage('Build') {
            steps {
                echo 'Build sedang berjalan'
            }
        }
    }
}

options { timeout(time: 1, unit: 'HOURS') } membatasi total durasi seluruh pipeline menjadi satu jam — setelah itu build dibatalkan otomatis. Ini jaring pengaman terakhir. Sedangkan timeout(time: 15, unit: 'MINUTES') di sekitar step input membatasi hanya waktu menunggu persetujuan, sehingga pipeline batal dengan cepat jika tidak ada yang meng-approve, tanpa mengorbankan waktu build normal.

#Contoh Pipeline Lengkap

Semua konsep di atas digabung dalam satu Jenkinsfile: parameter untuk mengendalikan versi dan environment, saklar boolean untuk melewati test, approval gate sebelum deploy, dan timeout sebagai jaring pengaman:

Jenkinsfile parameterized dengan approval gate

pipeline {
    agent any
 
    parameters {
        string(name: 'APP_VERSION', defaultValue: '1.0.0', description: 'Versi aplikasi')
        choice(name: 'ENVIRONMENT', choices: ['staging', 'production'], description: 'Target environment')
        booleanParam(name: 'RUN_TESTS', defaultValue: true, description: 'Jalankan test suite')
        password(name: 'DEPLOY_TOKEN', defaultValue: '', description: 'Token deployment')
    }
 
    options {
        timeout(time: 1, unit: 'HOURS')
        buildDiscarder(logRotator(numToKeepStr: '10'))
    }
 
    stages {
        stage('Build') {
            steps {
                echo "Membangun versi ${params.APP_VERSION} untuk ${params.ENVIRONMENT}"
                sh "make build VERSION=${params.APP_VERSION}"
            }
        }
 
        stage('Test') {
            when {
                expression { return params.RUN_TESTS }
            }
            steps {
                sh 'make test'
            }
        }
 
        stage('Persetujuan') {
            steps {
                input message: 'Deploy ke Production?', submitter: 'admin-user'
            }
        }
 
        stage('Deploy') {
            steps {
                sh "make deploy ENV=${params.ENVIRONMENT}"
            }
        }
    }
}

Alur lengkapnya: user mengisi form → build berjalan dengan versi dan environment pilihan → test dijalankan hanya jika saklar aktif → pipeline berhenti di stage Persetujuan sampai admin-user klik Proceed → baru setelah itu stage Deploy dieksekusi. Jika parameter ENVIRONMENT diisi staging, pipeline berjalan tanpa approval yang ketat; pilihan production seharusnya selalu melewati gerbang persetujuan.

#Penutup

Pada episode 6 ini kita membedah cara membuat pipeline yang interaktif dan bisa dipertanggungjawabkan: parameterized pipeline dengan string, choice, booleanParam, dan password yang mengubah Jenkinsfile statis menjadi formulir, akses nilai lewat params, manual approval gate dengan step input yang menjeda pipeline sampai orang berwenang menyetujui, serta timeout handling di level pipeline dan di sekitar step persetujuan agar tidak ada build yang menggantung.

Inti yang harus kalian bawa:

• Parameter mengubah pipeline menjadi form; selalu sediakan defaultValue yang aman untuk trigger otomatis.
• params.X adalah cara eksplisit membaca nilai parameter di seluruh pipeline.
• Step input dengan submitter adalah gerbang persetujuan manusia; letakkan di stage terpisah agar mudah diaudit.
• options { timeout(time: 1, unit: 'HOURS') } membatasi durasi total; bungkus input dengan timeout lebih pendek agar pipeline batal cepat jika tidak di-approve.
• Jangan menaruh kredensial statis di parameter password — gunakan credentials store dari episode 5.

Sekarang kalian bisa membangun pipeline yang aman secara proses. Tapi pipeline sepanjang ini masih berjalan berurutan — satu stage menunggu stage sebelumnya selesai, dan itu sangat boros waktu. Di episode 7 berikutnya kita akan mempercepat segalanya: advanced flow control dengan eksekusi paralel, matrix strategy untuk build multi-environment, eksekusi kondisional dengan when, dan aksi pasca-build dengan post. Sampai jumpa di episode 7!