Jenkins Adalah: Fungsi, Cara Kerja, dan Kapan Dipakai

Setiap tim pengembang punya ritual yang sama ketika merilis perubahan ke server. Kode ditarik dari repositori, dependensi dipasang, aplikasi di-build (dikompilasi menjadi bentuk siap jalan), hasilnya diunggah lewat SSH, lalu layanan dijalankan ulang. Selama tim masih bertiga dan rilis terjadi seminggu sekali, ritual ini terasa wajar.

Masalah muncul saat frekuensi rilis naik. Satu langkah terlewat, dan aplikasi di server berbeda dari yang sudah diuji di komputer lokal. Anggota tim lain memakai versi Node.js yang berbeda, sehingga hasil build-nya ikut berbeda. Ketika sesuatu rusak di produksi, tidak ada catatan siapa merilis apa dan pada jam berapa.

Di titik inilah sebuah mesin perantara dibutuhkan — sesuatu yang menjalankan rangkaian langkah tadi dengan cara yang sama persis, setiap kali, tanpa bergantung pada ingatan manusia. Jenkins adalah salah satu jawaban paling tua sekaligus paling banyak dipakai untuk kebutuhan tersebut.

Apa Itu Jenkins?

Jenkins adalah automation server (server otomasi) open source yang menjalankan serangkaian perintah secara otomatis ketika terjadi peristiwa tertentu, paling sering ketika ada perubahan kode di repositori. Ia tidak menggantikan Git, tidak menggantikan server produksi Anda, dan tentu tidak menulis kode. Tugasnya sempit tetapi penting: menerima pemicu, menjalankan langkah yang sudah Anda definisikan, lalu melaporkan hasilnya.

Jenkins ditulis menggunakan bahasa pemrograman Java dan berjalan sebagai aplikasi mandiri dalam prosesnya sendiri. Versi stabil terbaru, LTS 2.568.1 yang dirilis 8 Juli 2026, hanya berjalan di Java 21 atau Java 25. Detail ini sering luput: instalasi lama yang masih memakai Java 11 atau Java 17 tidak dapat dinaikkan ke versi terbaru sebelum runtime Java-nya diganti.

Lisensinya MIT, salah satu lisensi open source paling permisif. Anda boleh memasang, memodifikasi, bahkan menjualnya kembali tanpa membayar sepeser pun. Sejak Maret 2019, proyek ini bernaung di bawah Continuous Delivery Foundation, sebuah yayasan di lingkungan Linux Foundation, dan menyandang status graduated sejak Agustus 2020.

Jika Anda menemukan nama "Hudson" di dokumentasi atau tutorial lama, itu bukan produk yang berbeda. Hudson adalah nama Jenkins sebelum tahun 2011.

CI/CD Adalah Praktik, Jenkins Adalah Alatnya

Dua istilah ini kerap tertukar di kepala pembaca yang baru masuk. CI/CD adalah cara kerja, sedangkan Jenkins adalah perangkat lunak yang menjalankannya. Perbedaan ini bukan soal kerapian istilah, melainkan menentukan cara Anda memilih alat: praktiknya tetap sama meski alatnya diganti.

Singkatannya sendiri memuat tiga konsep yang berbeda, meski hanya terdiri dari dua huruf pasangan:

1. Continuous integration (CI): setiap perubahan kode digabungkan ke cabang utama sesering mungkin, dan setiap penggabungan langsung diverifikasi lewat build dan uji otomatis. Tujuannya menemukan konflik dan kesalahan dalam hitungan menit, bukan setelah menumpuk berminggu-minggu.
2. Continuous delivery (CD): setelah lolos verifikasi, hasil build otomatis disiapkan sampai berstatus siap rilis. Keputusan menekan tombol rilis tetap di tangan manusia.
3. Continuous deployment (CD juga): satu langkah lebih jauh, hasil yang lolos verifikasi langsung diterapkan ke produksi tanpa persetujuan manual.

Banyak tim mengaku sudah menerapkan continuous deployment padahal yang berjalan adalah continuous delivery. Keduanya sah, dan bagi tim yang baru mulai, berhenti di continuous delivery justru pilihan yang lebih bijaksana.

Tiga kartu CI/CD: Continuous Integration, Continuous Delivery (paket bercentang), dan Continuous Deployment (menuju server).

Asal-Usul Nama Jenkins dan Perpisahan dari Hudson

Cerita Jenkins dimulai jauh sebelum istilah DevOps populer. Kohsuke Kawaguchi, seorang engineer di Sun Microsystems, merilis proyek bernama Hudson pada 7 Februari 2005. Selama beberapa tahun Hudson menjadi standar tidak resmi untuk continuous integration di dunia Java.

Situasinya berubah setelah Oracle mengakuisisi Sun. Ketegangan muncul soal siapa yang mengendalikan infrastruktur proyek, dan puncaknya terjadi pada Desember 2010 ketika Oracle mendaftarkan merek dagang atas nama "Hudson". Komunitas menyerukan pemungutan suara untuk mengganti nama pada 11 Januari 2011, dan proposal itu disetujui telak pada 29 Januari 2011. Lahirlah Jenkins.

Oracle memilih melanjutkan Hudson secara terpisah, tetapi mayoritas kontributor dan pengguna sudah berpindah. Hudson lalu diserahkan ke Eclipse Foundation pada akhir 2012, merilis versi terakhirnya (3.3.3) pada Februari 2016, dinyatakan usang pada Februari 2017, dan situs resminya tutup pada 31 Januari 2020.

Ada pelajaran yang tersisa dari peristiwa ini, dan berlaku untuk proyek open source mana pun yang Anda pakai hari ini: kode boleh berlisensi bebas, tetapi merek dagang tidak. Siapa yang memegang nama, memegang kendali atas arah proyek.

Cara Kerja Jenkins: Controller, Agent, dan Pipeline

Jenkins bekerja dengan memisahkan otak dan otot. Bagian yang mengatur disebut controller, dan bagian yang mengerjakan build disebut agent.

Controller adalah proses utama Jenkins. Ia menyimpan konfigurasi, menyediakan antarmuka web, menerima pemicu dari repositori, menjadwalkan pekerjaan, dan mengumpulkan hasilnya. Agent adalah mesin terpisah, entah server fisik, mesin virtual, atau container, yang benar-benar menjalankan perintah build. Satu controller dapat mengendalikan banyak agent dengan sistem operasi berbeda-beda.

Diagram arsitektur Jenkins: satu kotak Controller berikon monitor terhubung ke tiga kotak Agent berupa rak server.

Istilah resmi yang dipakai dokumentasi Jenkins sekarang adalah controller dan agent. Anda mungkin masih menemukan istilah lama "master" dan "slave" di tutorial berumur, dan keduanya merujuk pada hal yang sama.

Lapisan ketiga adalah pipeline, yaitu definisi tertulis mengenai langkah apa saja yang harus dijalankan. Pipeline ditulis dalam berkas bernama Jenkinsfile yang disimpan bersama kode aplikasi di dalam repositori. Karena ikut tersimpan di repositori, riwayat perubahan alur rilis dapat ditelusuri sama seperti riwayat perubahan kode.

Jenkins sebenarnya menyediakan dua gaya pekerjaan. Freestyle job dikonfigurasi lewat formulir di antarmuka web, cepat dibuat tetapi konfigurasinya hanya hidup di dalam server Jenkins. Pipeline ditulis sebagai kode di dalam Jenkinsfile. Untuk proyek yang akan hidup lama, pipeline hampir selalu pilihan yang lebih sehat, karena Anda dapat memulihkan seluruh alur rilis hanya dari repositori seandainya server Jenkins hilang.

Bentuk Jenkinsfile paling sederhana tidak serumit yang dibayangkan. Contoh berikut mendefinisikan tiga tahap untuk sebuah aplikasi Node.js, dan hanya menjalankan tahap rilis ketika perubahan berada di cabang main:

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'npm ci && npm run build'
            }
        }
        stage('Uji') {
            steps {
                sh 'npm test'
            }
        }
        stage('Rilis') {
            when { branch 'main' }
            steps {
                sh './deploy.sh'
            }
        }
    }
}

Baris agent any berarti Jenkins boleh memakai agent mana pun yang sedang menganggur. Perintah di dalam sh adalah perintah shell biasa, sama persis dengan yang Anda ketik di terminal. Blok when inilah yang membuat pipeline layak dipakai serius: tahap rilis hanya berjalan pada cabang tertentu, sehingga cabang percobaan tetap diuji tanpa pernah menyentuh produksi.

Alur satu siklus pipeline umumnya terlihat seperti ini:

Diagram alur kerja Jenkins dari kode Git, build otomatis, pengujian, hingga rilis atau pemberitahuan gagal.

Setiap tahap dalam Jenkinsfile disebut stage, dan setiap stage tampil sebagai kolom terpisah di antarmuka. Ketika ada kegagalan, Anda dapat langsung melihat stage mana yang gagal beserta log lengkapnya, tanpa perlu menebak.

Fungsi Jenkins di Alur Kerja Tim

Setelah memahami susunannya, fungsi Jenkins menjadi lebih konkret:

1. Menjalankan build otomatis: setiap kali kode masuk ke repositori, Jenkins mengambil kode terbaru dan membangunnya di lingkungan yang selalu sama. Perbedaan versi antar-komputer anggota tim berhenti menjadi sumber masalah.
2. Menjalankan uji otomatis: unit test, integration test, dan pemeriksaan kualitas kode dijalankan sebagai bagian dari pipeline. Kode yang gagal uji tidak akan pernah sampai ke tahap rilis.
3. Memberi umpan balik cepat: hasil build dikirim ke email atau kanal obrolan tim dalam hitungan menit. Semakin cepat kesalahan diketahui, semakin murah biaya memperbaikinya.
4. Menyimpan artefak dan riwayat: setiap build menghasilkan berkas keluaran siap pakai yang disebut artefak, misalnya berkas .jar atau folder hasil kompilasi. Jenkins menyimpannya beserta nomor build, waktu, dan pemicunya, sehingga Anda punya catatan lengkap ketika produksi bermasalah.
5. Menjalankan deployment: Jenkins dapat menyalin hasil build ke server tujuan, membangun image container, atau menerapkan konfigurasi ke klaster Kubernetes.
6. Menjadwalkan pekerjaan berkala: fungsi yang sering terlupakan. Jenkins dapat menjalankan pekerjaan terjadwal seperti backup basis data atau pembersihan berkas sementara. Anggap saja cron yang punya antarmuka, log tersimpan, dan pemberitahuan saat gagal.

Kekuatan Jenkins: Ekosistem 2.000+ Plugin

Pertanyaan yang wajar diajukan: kenapa perangkat lunak berusia dua dekade masih dipakai luas? Jawabannya terletak pada plugin.

Situs resmi plugin Jenkins mencatat lebih dari 2.000 plugin hasil kontribusi komunitas. Cakupannya sangat lebar: integrasi dengan Git dan penyedia repositori, integrasi Docker, pengelolaan kredensial, laporan hasil uji, pemberitahuan ke berbagai kanal, hingga autentikasi pengguna lewat direktori perusahaan.

Konsekuensi praktisnya, hampir tidak ada teknologi yang tidak bisa disentuh Jenkins. Pada dasarnya Jenkins menjalankan perintah di dalam shell, sehingga apa pun yang bisa Anda ketik di terminal bisa ia kerjakan. Bahasa pemrograman apa pun, alat build apa pun, target rilis apa pun.

Kekuatan kedua adalah kendali penuh. Jenkins berjalan di infrastruktur Anda sendiri, sehingga kode tidak perlu keluar dari jaringan internal. Tidak ada batas menit build bulanan, tidak ada tagihan yang membengkak ketika jumlah build naik, dan Anda bebas memakai perangkat keras khusus seperti mesin ber-RAM besar atau perangkat pengujian tertentu.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Kendali penuh selalu datang bersama tanggung jawab penuh. Inilah sisi yang perlu Anda hitung sebelum memutuskan.

Gratis diunduh, tidak gratis dijalankan. Jenkins membutuhkan server yang menyala 24 jam. Dokumentasi resminya menyebut kebutuhan RAM controller berkisar dari 200 MB untuk instalasi kecil sampai lebih dari 70 GB untuk instalasi masif. Angka pastinya sengaja tidak diberikan karena terlalu bergantung pada beban kerja. Sebagai titik awal yang masuk akal untuk tim kurang dari sepuluh orang, siapkan 2 vCPU, 4 GB RAM, dan 40 GB penyimpanan. Ukuran itu memadai selama build yang berjalan tergolong ringan. Kebutuhan seperti ini paling ekonomis dipenuhi oleh sebuah VPS; jika Anda belum memilikinya, layanan VPS Indonesia dengan akses root sudah memadai untuk memulai.

Plugin adalah pekerjaan rutin. Angka 2.000+ plugin memang mengesankan, tetapi setiap plugin yang Anda pasang adalah kode pihak ketiga yang berjalan dengan hak akses penuh di dalam Jenkins. Sebagian plugin dirawat aktif, sebagian lagi ditinggalkan pembuatnya. Memperbarui plugin secara berkala dan membaca pengumuman keamanan Jenkins menjadi bagian dari pekerjaan, bukan kegiatan tambahan.

Syarat Java terus naik. Riwayatnya cukup jelas. Java 8 masih didukung sampai LTS 2.60.1 pada Juni 2017. Java 17 menjadi syarat minimum sejak LTS 2.346.1 pada Juni 2022, lalu Java 21 sejak LTS 2.479.1 pada Oktober 2024. Versi hari ini menuntut Java 21 atau 25. Instalasi yang dibiarkan tidak diperbarui selama dua tahun berisiko tertinggal cukup jauh sehingga proses naik versinya menjadi pekerjaan tersendiri.

Build tidak boleh dijalankan di controller. Dokumentasi keamanan Jenkins menyatakan bahwa build yang berjalan di built-in node memiliki tingkat akses yang sama dengan proses Jenkins terhadap sistem berkas controller. Artinya, satu skrip build yang berbahaya dapat membaca seluruh kredensial yang tersimpan. Anjuran resminya adalah menyetel jumlah executor (slot yang menentukan berapa build boleh berjalan bersamaan di satu mesin) pada built-in node menjadi 0, lalu memakai agent terpisah. Sejak Jenkins 2.326, mekanisme Agent → Controller Access Control juga wajib aktif untuk menahan agent yang sudah dikuasai penyerang.

Kurva belajar Jenkinsfile. Pipeline ditulis dengan sintaks berbasis Groovy yang punya dua gaya, deklaratif dan skrip. Bagi tim yang terbiasa dengan berkas konfigurasi YAML sederhana, tahap awal akan terasa berat.

Kapan Jenkins Masih Layak Dipakai, Kapan Sebaiknya Tidak

Lanskapnya sudah berubah. Laporan State of Developer Ecosystem 2025 dari JetBrains mencatat GitHub Actions dipakai 33% responden di tingkat organisasi, Jenkins 28%, dan GitLab CI 19%. Jarak itu melebar tajam pada proyek pribadi: GitHub Actions 39%, Jenkins hanya 13%. Laporan yang sama juga mencatat 18% responden belum memakai alat CI/CD sama sekali.

Angka tersebut tidak berarti Jenkins sudah usang. Yang berubah adalah posisinya: dari pilihan bawaan menjadi pilihan yang perlu alasan.

Jenkins masih menjadi pilihan tepat dalam tiga situasi. Pertama, ketika kode atau data tidak boleh keluar dari jaringan internal karena alasan kepatuhan, misalnya di lembaga keuangan dan instansi pemerintah. Kedua, ketika build membutuhkan perangkat keras khusus yang tidak disediakan runner cloud, seperti mesin ber-RAM sangat besar atau perangkat fisik untuk pengujian. Ketiga, ketika alur rilis Anda terlalu berliku untuk dituangkan ke dalam YAML bawaan penyedia repositori.

Sebaliknya, untuk repositori kecil yang sudah berada di GitHub atau GitLab, dengan tim di bawah sepuluh orang dan alur rilis yang lurus, CI bawaan platform tersebut lebih hemat waktu. Anda tidak perlu merawat server, tidak perlu memikirkan versi Java, dan kuota gratisnya umumnya sudah mencukupi. Memasang Jenkins untuk kebutuhan sebesar itu berarti menambah satu server lagi yang harus dijaga tanpa imbalan yang sepadan.

Mencoba Jenkins dengan Cepat

Cara tercepat mengenal Jenkins tanpa mengotori komputer Anda adalah menjalankannya sebagai container. Perintah berikut menjalankan Jenkins LTS beserta Java 21 dan menyimpan datanya di volume bernama jenkins_home:

docker run -d --name jenkins \
  -p 8080:8080 -p 50000:50000 \
  -v jenkins_home:/var/jenkins_home \
  jenkins/jenkins:lts-jdk21

Port 8080 dipakai untuk antarmuka web, sedangkan port 50000 dipakai agent untuk terhubung ke controller. Volume jenkins_home penting karena seluruh konfigurasi, riwayat build, dan plugin tersimpan di sana; tanpa volume, semuanya hilang saat container dihapus.

Buka http://localhost:8080 di peramban, lalu Jenkins akan meminta kata sandi awal. Ambil kata sandi tersebut dengan perintah berikut:

docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

Setelah masuk, pilih opsi pemasangan plugin yang disarankan, buat akun administrator, dan Anda sudah dapat membuat pipeline pertama. Perlu diperhatikan, susunan ini hanya untuk mengenal Jenkins di komputer sendiri. Pemasangan untuk produksi membutuhkan HTTPS, agent terpisah, pencadangan jenkins_home, dan pembatasan akses jaringan.

Pertanyaan yang Sering Muncul

Apakah Jenkins gratis atau berbayar?

Jenkins sepenuhnya gratis dan berlisensi MIT. Yang berbiaya adalah server tempat ia berjalan serta waktu yang Anda habiskan untuk merawatnya.

Jenkins menggunakan bahasa pemrograman apa?

Jenkins sendiri ditulis dengan Java dan membutuhkan Java 21 atau 25 untuk berjalan. Pipeline-nya ditulis dengan sintaks berbasis Groovy. Namun aplikasi yang Anda bangun tidak harus berbahasa Java, karena Jenkins pada dasarnya menjalankan perintah shell.

Apa perbedaan Jenkins dan Docker?

Keduanya menyelesaikan masalah yang berbeda. Docker mengemas aplikasi beserta seluruh kebutuhannya ke dalam container agar berjalan seragam di mana pun. Jenkins mengatur kapan dan bagaimana proses build serta rilis dijalankan. Keduanya justru sering dipakai bersamaan: Jenkins menjalankan pipeline yang membangun image Docker.

Apakah Jenkins hanya untuk proyek Java?

Tidak. Anggapan ini muncul karena Jenkins lahir dari komunitas Java. Karena ia menjalankan perintah shell, proyek PHP, Python, Node.js, Go, maupun aplikasi mobile sama-sama dapat dibangun dengan Jenkins.

Berapa kebutuhan RAM minimum untuk Jenkins?

Dokumentasi resmi menyebut instalasi kecil dapat berjalan dengan RAM 200 MB. Untuk pemakaian nyata oleh tim kecil, sediakan 4 GB agar controller dan beberapa build ringan dapat berjalan berdampingan dengan nyaman.

Kesimpulan

Jenkins adalah server otomasi open source yang menjalankan praktik CI/CD: mengambil kode setiap kali berubah, membangunnya, mengujinya, lalu merilisnya tanpa bergantung pada ingatan manusia. Kekuatannya terletak pada ekosistem lebih dari 2.000 plugin dan kendali penuh atas infrastruktur sendiri. Biayanya berupa server yang harus menyala terus, pembaruan Java berkala, dan perawatan plugin yang tidak pernah benar-benar selesai.

Pakailah Jenkins ketika kode Anda tidak boleh keluar dari jaringan sendiri, ketika build membutuhkan perangkat keras khusus, atau ketika alur rilis Anda terlalu rumit untuk konfigurasi bawaan penyedia repositori. Untuk proyek kecil yang repositorinya sudah berada di GitHub atau GitLab, CI bawaan platform tersebut akan lebih menghemat waktu Anda.

Semoga artikel ini membantu.