Mengapa Pipeline Anda Membutuhkan Strategi Penyimpanan Artifact yang Tepat
Anda baru saja selesai membangun aplikasi. Semua pengujian lulus. Pemindaian keamanan tidak menemukan apa pun. Log build menunjukkan centang hijau yang bersih. Sekarang saatnya untuk melakukan deployment. Namun, saat Anda membuka dasbor deployment, Anda menyadari bahwa Anda tidak tahu artifact mana yang harus digunakan. Server build sudah membersihkan ruang kerjanya. Pengembang yang menjalankan build sedang cuti. Satu-satunya yang tersisa adalah ingatan samar bahwa "build berhasil."
Skenario ini lebih umum daripada yang diakui sebagian besar tim. Build berhasil, tetapi artifact menghilang. Atau lebih buruk lagi, pipeline deployment membangun ulang artifact dari awal di lingkungan produksi, menggunakan versi dependensi yang berbeda, menghasilkan sesuatu yang tidak pernah diuji.
Masalahnya bukan pada build-nya. Masalahnya adalah artifact diperlakukan sebagai file sementara, bukan sebagai hasil kiriman yang terverifikasi yang perlu disimpan, diberi label, dan dilacak.
Apa Arti Sebenarnya dari Package dan Publish
Ketika pipeline Anda selesai melakukan pengujian dan pemindaian, pipeline memasuki fase yang sering dilewatkan oleh banyak tim: packaging dan publishing. Dua langkah inilah yang mengubah build yang berhasil menjadi aset yang dapat digunakan kembali.
Packaging adalah proses mengonversi kode yang telah terverifikasi menjadi format yang dapat berjalan di lingkungan target Anda. Formatnya tergantung pada apa yang Anda bangun:
- Untuk aplikasi berbasis kontainer, packaging berarti membuat image kontainer.
- Untuk aplikasi Java, berarti menghasilkan file JAR atau WAR.
- Untuk pustaka JavaScript atau Python, berarti membuat paket yang dapat diinstal oleh npm atau pip.
- Untuk infrastruktur, ini mungkin berarti menghasilkan modul Terraform atau template CloudFormation yang telah divalidasi.
Publishing adalah tindakan mengirim artifact yang telah dikemas tersebut ke registry atau repositori yang nantinya dapat diakses oleh pipeline deployment. Registry bukan sekadar bucket penyimpanan. Registry adalah sistem terstruktur yang menjaga artifact Anda tetap terorganisir, berversi, dan dapat ditemukan.
Berikut adalah cuplikan YAML minimal yang menunjukkan bagaimana pipeline CI mengemas image kontainer dan mempublikasikannya dengan tag versi unik:
- name: Build and tag Docker image
run: |
docker build -t myregistry.com/myapp:1.0.0-b20240315-a1b2c3d .
- name: Push image to registry
run: |
docker push myregistry.com/myapp:1.0.0-b20240315-a1b2c3d
Image kontainer masuk ke registry kontainer seperti Docker Hub, Amazon ECR, atau Harbor. Paket aplikasi masuk ke repositori artifact seperti Nexus, Artifactory, atau GitHub Packages. Modul infrastruktur masuk ke registry modul atau repositori Git dengan penandaan yang tepat.
Satu Hal yang Menentukan Keberhasilan Fase Ini
Versioning bukanlah opsional. Setiap artifact yang Anda publikasikan harus memiliki versi yang unik dan dapat dilacak. Ini bukan tentang mengikuti semantic versioning agar terlihat profesional. Ini tentang dapat menjawab satu pertanyaan: "Apa yang sebenarnya berjalan di produksi saat ini?"
Jika artifact Anda diberi label latest atau stable, Anda tidak dapat menjawab pertanyaan itu. Label tersebut berubah seiring waktu. Label itu tidak memberi tahu Anda apa pun tentang perubahan kode di dalamnya. Ketika bug muncul di produksi dan Anda perlu melacaknya kembali ke commit yang memperkenalkannya, label seperti latest tidak memberikan informasi apa pun.
String versi yang baik menggabungkan versi semantik dengan metadata build. Sesuatu seperti 1.2.3-b20240315-a1b2c3d memberi tahu Anda nomor rilis, tanggal build, dan hash commit. Ini cukup untuk melacak artifact kembali ke kode sumber yang tepat, job build yang tepat, dan hasil pengujian yang tepat.
Metadata Adalah Jaring Pengaman Anda
String versi saja berguna, tetapi tidak cukup. Setiap artifact yang dipublikasikan harus membawa metadata yang mencatat:
- Hash commit yang memicu build
- Nama cabang
- Nomor build
- Ringkasan hasil pengujian
- Siapa yang memicu build
Untuk image kontainer, metadata ini masuk ke dalam label. Untuk file paket, metadata masuk ke dalam manifes atau file metadata pendamping. Metadata ini mengubah artifact Anda dari kotak hitam menjadi aset yang terdokumentasi. Ketika seseorang bertanya "Apakah artifact ini lulus semua pengujian yang diperlukan?", Anda dapat menunjuk ke metadata dan membuktikan bahwa ia lulus.
Mengapa Ini Penting untuk Keyakinan Deployment
Setelah artifact Anda dikemas, diberi versi, dan dipublikasikan dengan metadata, pipeline deployment Anda dapat menariknya dengan percaya diri. Langkah deployment menjadi operasi sederhana: ambil artifact versi X, deploy ke lingkungan Y.
Tanpa fondasi ini, deployment menjadi tebakan. Tim akhirnya membangun ulang artifact di lingkungan produksi karena output build asli sudah hilang. Membangun ulang di produksi berbahaya. Build mungkin menggunakan versi dependensi yang berbeda, kompiler yang berbeda, atau image dasar yang berbeda. Hasilnya adalah artifact yang tidak pernah diuji, berjalan di lingkungan di mana kegagalan sangat merugikan.
Artifact yang disimpan dengan benar menghilangkan risiko ini. Artifact yang lulus semua pengujian adalah artifact yang sama persis yang di-deploy. Tidak ada pembangunan ulang. Tidak ada kejutan.
Opsi Registry Umum
Anda tidak memerlukan solusi enterprise yang mahal untuk melakukannya dengan benar. Yang penting adalah memilih registry yang sesuai dengan tumpukan teknologi Anda dan menggunakannya secara konsisten.
- Image kontainer: Docker Hub, Amazon ECR, Google Artifact Registry, Harbor, atau registry apa pun yang sesuai dengan OCI.
- Paket aplikasi: Nexus, Artifactory, GitHub Packages, GitLab Package Registry, atau registry khusus bahasa seperti npm atau PyPI.
- Modul infrastruktur: Terraform Cloud, Git dengan tag semantik, atau registry modul khusus.
Registry itu sendiri tidak terlalu penting dibandingkan dengan cara Anda menggunakannya. Registry sederhana dengan versioning ketat dan metadata lebih baik daripada registry canggih di mana semua orang mendorong artifact dengan label acak.
Daftar Periksa Singkat untuk Pipeline Anda
Jika Anda sedang menyiapkan atau meninjau tahap packaging dan publishing Anda, jalankan pemeriksaan berikut:
- Setiap artifact memiliki versi unik yang menyertakan hash commit atau nomor build.
- Tidak ada artifact yang dipublikasikan dengan label seperti
latestuntuk penggunaan produksi. - Metadata (hash commit, cabang, nomor build, status pengujian) dilampirkan pada setiap artifact yang dipublikasikan.
- Server build tidak membersihkan artifact segera setelah build selesai.
- Pipeline deployment menarik artifact dari registry, tidak pernah membangunnya kembali.
- Registry memiliki kebijakan retensi yang mencegah penghapusan tidak sengaja artifact produksi.
Apa Selanjutnya
Dengan artifact Anda yang tersimpan dengan aman dan dapat dilacak, langkah selanjutnya adalah deployment. Namun, sebelum melanjutkan, luangkan waktu sejenak untuk memverifikasi bahwa registry Anda diatur dengan cukup baik untuk mendukung rollback. Jika Anda perlu kembali ke versi sebelumnya, dapatkah Anda menemukan artifact yang tepat dari deployment minggu lalu? Jika jawabannya tidak, strategi penyimpanan Anda masih memiliki celah.
Artifact yang disimpan dengan baik adalah fondasi dari deployment yang dapat diulang dan dapat diandalkan. Tanpanya, setiap deployment membawa risiko tersembunyi. Dengannya, Anda dapat melakukan deployment dengan mengetahui bahwa apa yang Anda jalankan persis seperti yang Anda uji.