3-3 · Bab 3 · 4 menit baca

Mengapa Setiap Artifact Perlu Nama dan Nomor

Pelajari pentingnya memberi nama dan nomor versi pada setiap artifact CI/CD. Panduan praktis untuk DevOps, SRE, dan platform engineer agar deployment lebih andal.

Mengapa Setiap Artifact Perlu Nama dan Nomor

Tim Anda membangun kode setiap hari. Menjelang Jumat, sudah ada tujuh artifact berbeda di repositori. Tidak ada yang ingat mana yang sudah diuji, mana yang berisi hotfix, dan mana yang harus naik ke produksi. Seseorang bertanya, "Build mana yang kita deploy?" dan jawabannya hanya berupa bahu yang diangkat.

Inilah momen ketika Anda sadar bahwa artifact tanpa penamaan yang jelas bukanlah artifact sejati. Mereka hanyalah file. Tanpa sistem penamaan dan penomoran yang tepat, pipeline Anda hanya menghasilkan kebisingan, bukan kepastian.

Masalah Artifact Tanpa Label

Ketika artifact tidak memiliki identitas yang jelas, setiap deployment menjadi tebak-tebakan. Tim mulai bergantung pada timestamp, nama folder, atau ingatan. "Sepertinya build hari Selasa sore yang ada perbaikannya." Cara berpikir seperti itu berbahaya. Ini bisa menyebabkan deploy versi yang salah, rollback ke sesuatu yang belum pernah diuji, atau lebih parah lagi, deploy artifact yang rusak karena tidak ada yang tahu mana yang terbaru.

Inti masalahnya sederhana: jika Anda tidak bisa mengidentifikasi artifact secara unik, Anda tidak bisa mendeploynya dengan andal. Dan jika Anda tidak bisa mendeploy dengan andal, Anda tidak bisa merilis dengan percaya diri.

Apa yang Membuat Artifact Dapat Diidentifikasi

Setiap artifact membutuhkan dua hal: nama dan nomor. Nama memberi tahu Anda apa artifact itu. Nomor memberi tahu Anda versi mana dari artifact tersebut. Bersama-sama, keduanya menciptakan pengidentifikasi unik yang bisa dirujuk oleh semua orang di tim tanpa ambiguitas.

Nama biasanya adalah nama aplikasi atau komponen. Nomor adalah versi. Ketika digabungkan, Anda mendapatkan sesuatu seperti payment-service-2.1.3. String tersebut merujuk tepat pada satu artifact. Bukan yang dari minggu lalu. Bukan yang namanya mirip. Hanya yang itu.

Versioning Bukan Sekadar Pemanis

Versioning adalah sistem yang memberikan makna pada bagian nomor dari pengidentifikasi artifact Anda. Ini bukan sekadar penghitung yang naik terus. Skema versioning yang baik memberi tahu Anda sesuatu tentang artifact itu sendiri. Ia mengomunikasikan sifat perubahan, tingkat risiko, dan hubungan dengan versi sebelumnya.

Sistem yang paling banyak digunakan adalah semantic versioning. Sistem ini menggunakan tiga angka yang dipisahkan oleh titik: MAJOR.MINOR.PATCH. Setiap angka memiliki makna spesifik.

MAJOR bertambah ketika Anda membuat perubahan yang memutus kompatibilitas mundur. Jika pengguna yang sudah ada perlu mengubah kode atau alur kerja mereka, itu adalah kenaikan versi major.
MINOR bertambah ketika Anda menambahkan fitur baru yang masih berfungsi dengan cara lama. Pengguna dapat meningkatkan versi tanpa merusak apa pun.
PATCH bertambah untuk perbaikan bug yang tidak memperkenalkan fitur baru atau merusak fungsionalitas yang sudah ada.

Ketika Anda melihat versi 2.1.3, Anda tahu aplikasi tersebut telah melalui dua perubahan besar yang memutus kompatibilitas, satu penambahan fitur, dan tiga perbaikan bug. Itu adalah banyak informasi yang dikemas dalam string pendek.

Imutabilitas Dimulai dari Versioning

Nomor versi bukan sekadar label. Ia adalah kontrak. Setelah artifact dibangun dan diberi tag dengan sebuah versi, versi itu tidak boleh berubah. Jika Anda membangun ulang kode yang sama, Anda harus mendapatkan artifact yang sama. Jika ada yang berubah, versinya harus berubah.

Inilah yang membuat artifact menjadi immutable. Versi 2.1.3 selalu merujuk pada binary yang sama, image container yang sama, paket yang sama. Tidak peduli apakah Anda mengunduhnya hari ini, minggu depan, atau enam bulan kemudian. Artifactnya identik. Kepastian inilah yang memungkinkan Anda menguji sesuatu di staging, lalu mendeploy hal yang persis sama ke produksi tanpa kejutan.

Versioning dan Rilis Itu Berbeda

Kesalahan umum adalah memperlakukan versioning dan rilis sebagai konsep yang sama. Padahal tidak. Versioning adalah tentang memberi label pada artifact. Rilis adalah tentang memutuskan untuk membuat artifact tersebut tersedia bagi pengguna.

Anda dapat membangun versi 2.2.0-beta dan mendeploynya ke staging untuk pengujian. Versi itu ada sebagai artifact, tetapi bukan sebuah rilis. Setelah pengujian, Anda mungkin memutuskan untuk mempromosikannya menjadi 2.2.0 dan merilisnya ke produksi. Atau Anda mungkin menemukan masalah dan membangun 2.2.1 sebagai gantinya.

Pemisahan ini memberi Anda fleksibilitas. Anda dapat sering membangun dan memberi versi pada artifact, tetapi hanya merilis ketika Anda yakin. Nomor versi melacak identitas artifact. Keputusan rilis melacak kesiapannya.

Implikasi Praktis untuk Pipeline Anda

Setelah Anda memiliki sistem penamaan dan versioning yang jelas, beberapa hal menjadi lebih mudah.

Ketertelusuran menjadi otomatis. Ketika sebuah bug dilaporkan di produksi, Anda melihat versi yang berjalan di lingkungan tersebut. Anda memeriksa perubahan apa saja yang masuk ke versi itu. Anda membandingkannya dengan versi stabil sebelumnya. Semua ini dimungkinkan karena setiap artifact memiliki pengidentifikasi unik yang terhubung kembali ke kode sumber dan proses build.

Rollback menjadi presisi. Anda tidak perlu menebak versi mana yang berfungsi sebelumnya. Anda tahu persis versi mana yang berjalan minggu lalu, dan Anda dapat mendeploy artifact yang sama lagi. Karena artifact bersifat immutable, Anda mendeploy binary yang persis sama, bukan build ulang yang mungkin berperilaku berbeda.

Komunikasi menjadi lebih jelas. Alih-alih mengatakan "deploy build terbaru," Anda mengatakan "deploy payment-service 2.1.3 ke produksi." Semua orang tahu persis apa artinya itu. DBA tahu migrasi database apa yang diharapkan. Tim QA tahu pengujian mana yang telah dijalankan. Tim operasi tahu apa yang harus dipantau.

Daftar Periksa Sederhana untuk Penamaan Artifact

Jika Anda baru pertama kali menyiapkan penamaan artifact, berikut adalah daftar periksa singkat untuk memulai:

Setiap artifact memiliki nama yang sesuai dengan nama aplikasi atau komponen.
Setiap artifact memiliki nomor versi yang mengikuti skema yang konsisten.
Nomor versi ditetapkan pada waktu build dan tidak pernah diubah setelahnya.
Repositori artifact menyimpan artifact berdasarkan nama dan versi, bukan berdasarkan timestamp atau folder.
Tim memahami perbedaan antara versioning (memberi label) dan rilis (menyediakan).
Skema versioning mengomunikasikan sifat perubahan (major, minor, patch).

Kesimpulan

Penamaan dan versioning artifact bukanlah latihan birokrasi. Ini adalah fondasi dari deployment yang andal. Tanpanya, pipeline Anda menghasilkan ketidakpastian. Dengannya, setiap artifact memiliki identitas yang jelas, setiap deployment memiliki target yang jelas, dan setiap rollback memiliki tujuan yang jelas. Beri nama artifact Anda. Beri nomor secara konsisten. Buatlah immutable. Maka Anda dapat mendeploy dengan percaya diri.