Kemana Hasil Build Anda? Bagian yang Hilang Antara Kode dan Produksi

Anda baru saja selesai membangun aplikasi. Build berhasil, pengujian lolos, dan kini ada artifact baru yang mengilap di folder laptop Anda. Lalu bagaimana?

Jika Anda seperti kebanyakan tim yang baru menyiapkan pipeline pertama, langkah selanjutnya terasa jelas: deploy. Tapi ada masalah yang tersembunyi di depan mata. Artifact di laptop Anda tidak berguna bagi server produksi yang berada di pusat data atau region cloud. Server itu tidak bisa menjangkau folder lokal Anda dan mengambil file tersebut. Bahkan jika build dijalankan di mesin CI khusus, target deployment tetap tidak bisa mengakses file yang ada di disk lokal mesin tersebut.

Di sinilah sebagian besar desain pipeline pertama kali menemui hambatan nyata. Anda membutuhkan tempat untuk meletakkan artifact yang bisa dijangkau oleh proses build dan target deployment.

Masalah Penyimpanan Bersama

Bayangkan apa yang terjadi saat Anda selesai memasak untuk sebuah pesta. Anda tidak menyimpan makanan di dapur dan berharap tamu masuk sendiri untuk mengambil dari kompor Anda. Anda meletakkan makanan di meja yang bisa dijangkau semua orang.

Artifact bekerja dengan cara yang sama. Proses build membuat artifact. Proses deployment perlu mengambilnya. Kedua proses ini mungkin berjalan di mesin yang berbeda, di jaringan yang berbeda, pada waktu yang berbeda. Mereka membutuhkan lokasi bersama yang bisa diakses keduanya melalui jaringan.

Lokasi bersama ini disebut artifact registry atau artifact repository. Tugasnya sederhana: menyimpan artifact dan menyediakan cara untuk mengambilnya. Setiap kali build selesai, ia mendorong artifact ke registry ini. Nanti, saat deployment dimulai, server target menarik artifact dari registry dan menjalankannya.

Diagram berikut menunjukkan alur dasarnya:

Berikut cara mendorong artifact setelah build dan menariknya di target deployment:

# Di mesin build: push artifact ke registry
curl -X POST \
  -F "file=@myapp-v1.2.3.jar" \
  https://registry.example.com/upload

# Di target deployment: pull artifact dari registry
curl -O https://registry.example.com/artifacts/myapp-v1.2.3.jar
flowchart TD A[Mesin Build] -->|push artifact| B[Artifact Registry] B -->|pull artifact| C[Target Deployment] D[Jaringan Berbeda] -.-> A E[Jaringan Berbeda] -.-> C F[Waktu Berbeda] -.-> A G[Waktu Berbeda] -.-> C

Lebih dari Sekadar File Server

Sebuah registry melakukan lebih dari sekadar menyimpan file. Ia juga menyimpan metadata tentang setiap artifact: nomor versi, stempel waktu pembuatan, dan seringkali hash commit Git yang menghasilkannya. Metadata ini menjadi kritis saat terjadi kesalahan di produksi.

Bayangkan Anda melakukan deploy versi 2.3.1 dan pengguna mulai melihat error. Anda perlu tahu persis perubahan kode apa yang masuk ke artifact tersebut. Tanpa metadata yang menghubungkan artifact kembali ke commit sumbernya, Anda hanya menebak. Dengan metadata, Anda bisa memeriksa diff, mengidentifikasi masalah, dan memutuskan apakah akan roll back atau fix forward.

Beberapa registry juga mendukung label atau tag. Anda bisa menandai artifact sebagai "staging-validated" setelah lolos pengujian integrasi, atau "production-ready" setelah persetujuan manual. Tag ini membantu mengotomatiskan artifact mana yang akan di-deploy ke lingkungan mana.

Jebakan Konektivitas

Ini adalah kesalahan yang sering menjebak banyak tim: mereka menyiapkan registry di cloud, tetapi server produksi mereka berjalan di jaringan privat yang tidak bisa menjangkau internet publik. Build berhasil mendorong artifact, tetapi saat deployment mencoba menarik, gagal dengan connection timeout.

Registry harus dapat diakses dari setiap server yang perlu melakukan deploy. Jika lingkungan produksi Anda terisolasi, registry Anda harus berada di dalam jaringan yang sama, atau Anda memerlukan mekanisme untuk menyinkronkan artifact melintasi batas jaringan. Beberapa tim menjalankan proxy atau mirror lokal yang menyimpan cache artifact dari registry pusat. Yang lain menggunakan registry yang mendukung endpoint jaringan privat.

Kedengarannya jelas saat Anda membacanya, tetapi mudah terlewatkan saat Anda fokus membuat pipeline berfungsi dari ujung ke ujung. Periksa konektivitas sebelum Anda membangun seluruh proses deployment di sekitar registry yang tidak bisa dijangkau server Anda.

Imutabilitas Itu Penting

Registry yang baik mencegah artifact dimodifikasi setelah disimpan. Properti ini disebut imutabilitas. Artinya, artifact yang Anda simpan hari ini akan identik dengan artifact yang Anda ambil enam bulan dari sekarang.

Mengapa ini penting? Tanpa imutabilitas, Anda tidak bisa mempercayai apa yang Anda deploy. Seseorang bisa memodifikasi artifact setelah lolos pengujian. Bug yang tertangkap di staging bisa muncul kembali di produksi karena artifact berubah antar lingkungan. Debugging menjadi mimpi buruk karena Anda tidak pernah yakin apakah artifact yang berjalan di produksi cocok dengan yang diuji.

Imutabilitas memaksa alur kerja yang bersih: setiap perubahan menghasilkan artifact baru dengan versi baru. Tidak ada "update di tempat" untuk artifact. Jika Anda perlu memperbaiki sesuatu, Anda membangun ulang dan membuat versi baru. Disiplin ini membuat deployment dapat diprediksi dan rollback menjadi mudah.

Mendekouple Build dari Deploy

Dengan registry yang ada, build dan deploy menjadi dua proses terpisah yang bisa berjalan secara independen. Build selesai, mendorong artifact, dan melanjutkan tugas lain. Deployment bisa terjadi beberapa menit, jam, atau hari kemudian. Artifact duduk aman di registry, menunggu untuk diambil.

Dekoupling ini sangat kuat. Anda bisa membangun dan menguji artifact di pagi hari, ditinjau oleh engineer senior di siang hari, dan di-deploy ke produksi di malam hari saat traffic rendah. Setiap langkah berjalan sesuai jadwalnya sendiri, tetapi semuanya merujuk pada artifact immutabel yang sama.

Ini juga berarti Anda bisa membangun ulang dan melakukan deploy ulang artifact yang sama ke beberapa lingkungan. Artifact yang lolos pengujian staging adalah artifact yang persis sama yang masuk ke produksi. Tidak ada kompilasi ulang, tidak ada build khusus lingkungan, tidak ada kejutan "di mesin saya berhasil".

Daftar Periksa Praktis Cepat

Saat menyiapkan artifact registry, verifikasi poin-poin ini:

  • Aksesibilitas: Apakah setiap server yang perlu melakukan deploy dapat menjangkau registry melalui jaringan?
  • Imutabilitas: Apakah registry mencegah modifikasi artifact yang sudah disimpan?
  • Metadata: Apakah setiap artifact membawa informasi versi, stempel waktu, dan commit sumber?
  • Retensi: Berapa lama Anda menyimpan artifact lama? Apakah Anda memiliki kebijakan pembersihan?
  • Autentikasi: Siapa yang bisa mendorong artifact? Siapa yang bisa menariknya? Apakah kredensial dirotasi?

Kesimpulan

Output build Anda membutuhkan rumah yang bisa dijangkau oleh proses build dan target deployment. Artifact registry menyediakan penyimpanan bersama itu, menyimpan metadata untuk ketertelusuran, menegakkan imutabilitas sehingga Anda bisa mempercayai apa yang Anda deploy, dan mendekouple build dari deploy sehingga setiap langkah bisa berjalan dalam waktunya sendiri. Tanpa registry, pipeline Anda hanyalah build yang berakhir dengan file yang duduk di mesin yang tidak bisa dijangkau siapa pun.