Automated Image Build

Janji build deterministik dari chapter sebelumnya menyisakan satu pertanyaan yang mengganjal: kalau commit yang sama selalu melahirkan image yang sama, mengapa masih ada manusia yang duduk di depan laptop mengetik docker build dan docker push setiap kali kode berubah? Budi menghitung pengulangannya sendiri dan menemukan pola yang memalukan: sejak rilis 1.3.0, tidak satu pun dari belasan build-nya yang menghasilkan kejutan — bahan sama, hasil sama — sehingga pekerjaan itu murni ritual, dan ritual adalah pekerjaan yang paling layak diserahkan kepada mesin. Otomatisasi build image ternyata tidak hanya punya satu pintu; ada tiga jalur yang sama-sama sah, masing-masing dengan sejarah, wilayah kekuasaan, dan tagihan perawatannya sendiri. Chapter ini memetakan ketiganya, membandingkannya dari enam aspek yang menentukan, lalu menutup dengan pola pemicu — aturan penerjemahan dari peristiwa Git menjadi tag image — yang akan kita pakai terus sepanjang section ini.

Tiga Jalur Build Otomatis #

Ketiga jalur berikut menjawab pertanyaan yang sama: begitu kode bergerak, siapa yang membangun imagenya? Jawabannya bisa layanan CI, registry itu sendiri, atau mesin yang kita pasang sendiri — dan urutan pembahasannya mengikuti prioritas course.

Jalur 1: CI Build — Pipeline sebagai Kode #

Jalur pertama dan jalur utama course ini: pipeline yang ditulis sebagai berkas di dalam repositori dan dieksekusi layanan CI. Repositori GitHub menyimpan berkas workflow di folder .github/workflows/; setiap peristiwa — push ke cabang, tag rilis, pull request — dibaca layanan, lalu runner ephemeral disediakan untuk menjalankan langkah-langkah yang tertulis: test, build, push ke registry. Seluruh logika hidup di dalam repositori, diubah lewat pull request seperti kode biasa, dan setiap perubahan pipeline meninggalkan jejak Git yang bisa diaudit. Kekuatan jalur ini terletak pada gerbang mutu bertingkat: test dapat dijalankan sebelum build berhak dimulai, scan setelah image terdorong, dan persetujuan manusia sebelum deploy — seluruh ritual checklist produksi dapat ditanam sebagai langkah-langkah yang berbaris. GitHub Actions adalah contoh yang akan kita rakit tuntas mulai chapter berikutnya.

Jalur 2: Automated Build di Docker Hub #

Jalur kedua adalah fitur bawaan Docker Hub, dan sejarahnya melipat kebiasaan zaman awal container. Fitur Automated Builds lahir di Docker Hub pada masa-masa awal: repositori kode dihubungkan ke akun, dan setiap push ke branch atau tag tertentu langsung dibangun oleh infrastruktur Docker sendiri, dengan hasil yang muncul di repository Docker Hub milik pengguna. Fitur itu kemudian hijrah ke layanan Docker Cloud, hidup beberapa tahun di sana, lalu kembali ke Docker Hub sebagai kemampuan build yang terintegrasi — bagian dari pengalaman CI di Hub hingga hari ini. Cara kerjanya tetap sederhana: hubungkan repositori, tentukan build rule (branch atau tag Git mana yang membangun tag image apa), dan image lahir otomatis tanpa satu baris workflow. Jalur ini pas untuk proyek OSS sederhana — image publik dari repositori publik tanpa gerbang rumit — tetapi wilayahnya jelas: langkah build terbatas pada pola yang disediakan formulirnya, sehingga menjalankan test suite lengkap sebelum push atau memasang persetujuan manusia bukan lahan jalur ini.

Jalur 3: Webhook dan Build Server Sendiri #

Jalur ketiga adalah membangun sendiri: repositori (atau registry) mengirim webhook — notifikasi HTTP tentang suatu peristiwa — ke sebuah build server yang kita pasang dan kendalikan penuh. Pola ini tua tetapi tidak pernah mati, karena ada dunia yang tidak dapat meninggalkannya: kode di Git internal yang tidak tersambung internet, registry privat seperti registry.example.com di jaringan perusahaan, dan mesin legacy yang kebijakannya melarang layanan awan menyentuh kode. Build server — bisa Jenkins atau sekadar skrip yang ditrigger webhook — login ke registry privat dengan kredensial dari brankasnya sendiri, menjalankan docker build dan docker push, lalu melaporkan hasilnya. Kontrolnya mutlak: versi Docker, jadwal, dan urutan langkah semuanya milik tim. Harganya sepadan tapi nyata: mesin, pembaruan, dan keamanan runner menjadi tanggung jawab penuh tim — pekerjaan yang di jalur pertama dibayar oleh penyedia layanan.

Perbandingan Enam Aspek #

Ketiga jalur itu lebih mudah dipilih lewat tabel daripada lewat kata sifat. Enam aspek berikut adalah pertanyaan yang menentukan keputusan di dunia nyata, dari tim dua orang sampai perusahaan penuh:

Ketiga jalur itu bukan pesaing melainkan wilayah kekuasaan yang berbeda, dan memilihnya harus mengikuti keadaan, bukan tren. Untuk toko — repositori GitHub, tim yang tumbuh, kebutuhan gerbang test-scan-persetujuan — jalur CI build adalah pilihan alami, dan itulah jalur yang kita rakit sampai tuntas sepanjang sisa section ini. Automated build Docker Hub menemani dengan baik ketika Budi memelihara proyek OSS kecil di luar toko: repositori publik, image publik, tanpa gerbang yang rumit. Webhook dan build server sendiri menunggu di kantor-kantor yang kodenya tidak pernah meninggalkan intranet — dan bagi dunia itu, seluruh konsep section ini tetap berlaku; hanya mesin pengeksekusinya yang berpindah.

Pola Pemicu: Dari Peristiwa Git ke Tag Image #

Jalur mana pun yang dipilih, ada satu keputusan yang mendahului semuanya: bagaimana peristiwa Git diterjemahkan menjadi tag image. Tabel berikut adalah pola pemicu yang akan kita tanam ke pipeline toko — dan yang akan terlihat lagi sebagai baris tags: pada chapter berikutnya:

Demo pola ketiga datang langsung dari kalender rilis toko. Audit bulanan pada Chapter Checklist Production meninggalkan satu temuan berjadwal: CVE-2026-3928 tingkat High pada paket semver 5.7.1, dengan rencana naik ke 5.7.2 dan rebuild image. Budi menuntaskan kenaikan dependensi itu, menggabungkannya ke main, lalu memotong rilis dengan tag annotated:

$ git tag -a v1.6.0 -m "Rilis 1.6.0 - naikkan semver ke 5.7.2"
$ git push origin v1.6.0

Output yang Dihasilkan:

Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:budi/toko.git
 * [new tag]           v1.6.0 -> v1.6.0

Mari kita telaah peristiwa di atas:

1. git tag -a v1.6.0 -m "..." — tag annotated dibuat di atas commit hasil penggabungan; pesannya menyimpan ringkasan rilis yang dapat dibaca ulang kapan pun lewat git show v1.6.0.
2. git push origin v1.6.0 — perintah ini mengirim satu objek saja: tag beserta commit yang ditunjuknya; tidak ada branch yang ikut terdorong, dan tidak ada satu byte image yang berpindah.
3. * [new tag] — baris inilah peristiwa pemicunya: begitu workflow yang membaca pola tag v* terpasang nanti, baris sederhana ini yang menyalakan pipeline pembangun image rilis v1.6.0 — tanpa satu ketikan docker build pun dari Budi.

Pilihan jalur sudah diambil — toko membangun lewat CI — dan pola pemicunya sudah disepakati: push ke main melahirkan kandidat bergulir, tag v* melahirkan rilis. Tag v1.6.0 kini duduk di origin seperti undangan yang belum dibalas: sebuah peristiwa yang menunggu mesin pembacanya. Mesin itu bernama GitHub Actions, dan merakitnya — dari berkas workflow pertama sampai image yang terdorong ke ghcr.io — adalah pekerjaan chapter berikutnya.

Referensi #

• Docker build di layanan CI — dukungan build Docker pada berbagai layanan integrasi berkelanjutan.
• Builds di Docker Hub — automated build dan build rule pada Docker Hub.
• GitHub Actions — dokumentasi jalur CI build yang dipakai course ini.