Belajar Jenkins - Sejarah, Konsep & Arsitektur Utama

#Pendahuluan

Di episode 0 kita sudah menyalakan Jenkins pertama kali — ia berjalan di port 8080, lengkap dengan plugin dan user admin. Sekarang saatnya berhenti sejenak dari mengetik dan memahami apa sebenarnya yang sedang kalian jalankan. Episode ini membangun konteks: dari mana Jenkins berasal, mengapa sebuah tool berusia dua dekade masih menjadi tulang punggung CI/CD di perusahaan-perusahaan besar, dan bagaimana arsitektur intinya dirancang.

Konteks ini bukan sekadar trivia. Keputusan arsitektur yang kalian buat sebagai engineer — misalnya di mana build dijalankan, atau memilih Freestyle Project vs Pipeline — sangat dipengaruhi oleh pemahaman ini. Mari kita mulai dari asal-usulnya.

#Pembahasan Utama

#Dari Hudson ke Jenkins: Kisah Fork yang Sukses

Semuanya bermula pada tahun 2004, ketika Kohsuke Kawaguchi, seorang engineer di Sun Microsystems, menciptakan proyek bernama Hudson — sebuah continuous integration server yang pada masa itu menjadi salah satu yang pertama membuat konsep build yang diotomasi dan selalu terpantau menjadi mudah dipakai.

Tonggak sejarahnya:

Fork terjadi karena sengketa tata kelola: komunitas ingin pengembangan yang terbuka dan cepat, sementara Oracle menilai Hudson sebagai aset komersial. Analoginya mirip OpenOffice yang difork menjadi LibreOffice — fork tidak selalu berarti perpecahan yang melemahkan; kadang justru lahir proyek yang lebih sehat karena dikelola oleh orang-orang yang memakainya setiap hari. Hudson masih bertahan untuk beberapa waktu, tapi Jenkins dengan cepat merebut hampir seluruh ekosistem plugin dan pengguna.

#Mengapa Jenkins Tetap Populer di Skala Enterprise?

Dua dekade kemudian, muncul puluhan competitor — GitLab CI, GitHub Actions, CircleCI, Buildkite. Namun Jenkins tetap menjadi pilihan utama di banyak perusahaan. Alasannya bukan nostalgia, melainkan empat hal struktural:

1. Open source dan self-hosted dengan kontrol penuh. Jenkins berjalan di infrastruktur kalian sendiri. Data pipeline, riwayat build, dan artefak tidak pernah meninggalkan jaringan internal — ini wajib bagi industri yang diatur regulasi (finansial, kesehatan, pemerintahan) dan bagi tim yang ingin meminimalkan dependensi pada vendor.

2. Ekosistem 1800+ plugin. Hampir setiap tool yang pernah kalian dengar punya plugin Jenkins: Git, Docker, Kubernetes, Ansible, SonarQube, Slack, dan ribuan lainnya. Perluasannya organik selama dua dekade, jadi kemungkinan besar kebutuhan kalian sudah punya plugin yang matang.

3. Kustomisasi tanpa batas. Jenkins tidak memaksa alur kerja tertentu. Lewat Groovy, Jenkins Pipeline, dan Shared Libraries, kalian bisa membangun alur yang sangat kompleks — dari trigger, quality gate, hingga deployment berjenjang — yang mustahil dilakukan tool SaaS dengan batasan desain.

4. Komunitas dan sumber daya yang masif. Dokumentasi, buku, posting blog, dan engineer yang sudah berpengalaman Jenkins sangat banyak. Menarik talenta yang familiar dengan Jenkins jauh lebih mudah daripada tool yang lebih baru.

#Arsitektur Utama: Controller dan Agents

Ini konsep paling penting di seluruh series ini. Jenkins dirancang dengan arsitektur controller-agent:

• Jenkins Controller (dulu disebut master) adalah otaknya. Ia menyediakan UI web, REST API, penjadwalan (scheduling), manajemen plugin, dan orkestrasi seluruh pipeline. Semua konfigurasi disimpan di JENKINS_HOME.
• Jenkins Agents (dulu disebut slaves, kini juga nodes) adalah para pekerja. Setiap agent memiliki satu atau lebih executor — slot yang menjalankan satu build pada satu waktu — dan sebuah workspace (direktori kerja tempat source code di-checkout dan build dieksekusi).

Analoginya: controller adalah manajer restoran yang menerima pesanan, menyusun antrean, dan membagi tugas ke dapur; agent adalah para koki yang benar-benar memasak. Manajer tidak boleh ikut memasak jika koki bisa ditambah — kita akan membahas mengapa ini aturan keamanan nomor satu di episode 3.

Komunikasi antara controller dan agent bisa dua arah: agent outbound memulai koneksi ke controller (melalui port TCP 50000 — ingat kita sudah membuka port ini di episode 0), atau controller inbound yang memulai koneksi SSH ke agent. Dari perspektif pipeline, kalian tidak perlu peduli arah komunikasinya — yang penting pekerjaan bisa ditembakkan ke agent manapun.

#Alur Eksekusi Sebuah Build

Ketika sebuah job dipicu, yang terjadi adalah:

1. Controller menempatkan job ke dalam build queue.
2. Scheduler di controller memilih executor yang tersedia di agent yang cocok.
3. Agent menjalankan workspace: checkout source code, mengeksekusi langkah-langkah pipeline.
4. Agent mengirimkan log secara real-time ke controller untuk ditampilkan di UI.
5. Setelah selesai, controller mencatat hasil (success/failure), menyimpan artefak, dan menampilkan status.

Sekilas alur ini terlihat persis seperti pipeline yang akan kita tulis di episode 2 — karena memang itulah tujuannya: Jenkinsfile mendeskripsikan apa yang harus dikerjakan, dan arsitektur controller-agent yang mengeksekusinya. Contoh minimal sebuah pipeline yang berjalan di agent berlabel tertentu:

Pipeline yang diarahkan ke agent berlabel linux

pipeline {
    agent { label 'linux' }
    stages {
        stage('Build') {
            steps {
                echo 'Dijalankan di agent berlabel linux'
            }
        }
    }
}

Kalau ingin mengintip isi build queue dari terminal, Jenkins menyediakan REST API — misalnya curl http://localhost:8080/queue/api/json — yang menunjukkan antrean job yang sedang menunggu executor kosong. Ini cara cepat melihat bagian scheduling dari arsitektur yang baru saja kita bahas.

#Freestyle Project vs Jenkins Pipeline

Selain arsitektur fisik (controller/agent), ada juga arsitektur logis dalam mendefinisikan job: Freestyle Project dan Jenkins Pipeline.

Freestyle Project adalah cara klasik. Konfigurasi dilakukan lewat form UI: mengisi URL repository, menambahkan build steps satu per satu lewat dropdown, mengatur trigger lewat checkbox. Cepat untuk job sederhana, tapi tersebar di UI, sulit di-versioning, dan hampir tidak bisa dibuat kompleks.

Jenkins Pipeline mendefinisikan seluruh build sebagai kode di dalam file Jenkinsfile yang tersimpan di repository. Semua perubahan bisa di-review lewat pull request, bisa diuji secara lokal, dan bisa dibagikan antar proyek via Shared Libraries.

#Penutup

Pada episode 1 ini kalian telah memahami:

• Sejarah Jenkins: dari proyek Hudson tahun 2004, akuisisi Sun oleh Oracle, hingga fork menjadi Jenkins tahun 2011 yang kini dikelola komunitas.
• Alasan Jenkins tetap dominan di enterprise: open source self-hosted dengan kontrol data penuh, ekosistem 1800+ plugin, kustomisasi tanpa batas, dan komunitas yang masif.
• Arsitektur inti: controller sebagai orkestrator dan agent sebagai pekerja, dengan executor dan workspace, serta dua mode komunikasi (inbound dan outbound).
• Perbedaan mendasar Freestyle Project (ClickOps) dan Jenkins Pipeline (kode yang bisa di-versioning).

Inti yang harus kalian bawa: controller mengatur, agent yang bekerja, dan kode lebih baik daripada klik. Di episode 2 kita akan mulai menulis kode itu — membuat Jenkins Pipeline pertama dengan Jenkinsfile, memahami perbedaan sintaks Declarative dan Scripted, serta menjalankannya langsung dari Git via SCM checkout. Sampai jumpa di episode 2!