Tempat Penyimpanan Build: Mengapa Setiap Artefak Butuh Rumah

Bayangkan ini: pipeline CI Anda baru saja hijau. Seorang pengembang bertanya, "Build mana yang harus kita deploy ke staging?" Seseorang menjawab, "Yang dari build kemarin, sepertinya." Yang lain menimpali, "Tidak, saya rebuild secara lokal tadi pagi. Pakai punya saya."

Percakapan seperti ini lebih sering terjadi daripada yang diakui tim. Ketika artefak tersimpan di laptop, folder workspace CI, atau drive bersama seseorang, Anda kehilangan kemampuan untuk secara konsisten mengetahui apa yang benar-benar siap untuk di-deploy. Staging mungkin mendapatkan satu versi, production mendapatkan versi lain, dan tidak ada yang bisa melacak artefak mana yang menyebabkan insiden jam 2 pagi.

Perbaikannya sederhana secara konsep tetapi kritis dalam praktik: Anda memerlukan satu tempat terpusat di mana setiap hasil build berada. Dalam istilah DevOps, tempat itu disebut registry atau repository manager.

Artefak Datang dalam Berbagai Bentuk

Mari kita mulai dengan jenis artefak yang umum: file JAR, arsip ZIP, biner yang dikompilasi, atau paket NuGet. Ini adalah artefak file tunggal. Alat seperti Nexus, Artifactory, atau registry paket bawaan dari ekosistem bahasa Anda (npm registry, Maven Central, PyPI) menangani ini dengan baik. Mereka menyimpan file, melacak versi, dan memungkinkan pipeline atau pengembang menarik dependensi yang tepat yang mereka butuhkan.

Sekarang pertimbangkan image container. Image container bukanlah file tunggal. Ia dibangun dari beberapa lapisan yang ditumpuk satu sama lain. Anda tidak dapat menyimpan image container di registry artefak biasa. Ia membutuhkan container registry: Docker Hub, Amazon ECR, Google Container Registry, atau Harbor. Container registry memahami struktur lapisan. Ketika Anda menarik image, registry hanya mengirimkan lapisan yang belum ada di mesin target. Ini membuat deployment lebih cepat dan menghemat bandwidth.

Image container telah menjadi jenis artefak paling umum dalam pipeline CI/CD modern. Namun prinsipnya sama terlepas dari formatnya: registry adalah sumber kebenaran tunggal untuk setiap artefak yang lolos dari build dan pengujian Anda.

Registry Adalah Titik Handoff Antara CI dan CD

Inilah fungsi terpenting dari registry dalam pipeline: ia menandai batas antara continuous integration dan continuous delivery.

Diagram berikut membandingkan alur yang benar dengan alur yang rusak ketika tidak ada registry.

flowchart TD subgraph Correct[Dengan Registry] A1[CI Pipeline] -->|push artifact dengan versi| B1[Registry] B1 -->|pull artifact tepat| C1[CD Pipeline] C1 --> D1[Staging] C1 --> E1[Production] end subgraph Broken[Tanpa Registry] A2[CI Workspace] -->|salin manual| B2[Laptop] A2 -->|salin manual| C2[Shared Drive] B2 --> D2[Staging] C2 --> E2[Production] D2 -.->|ketidakcocokan versi| E2 end Correct -.->|kontras| Broken

Lihat alurnya. Tugas CI berakhir saat artefak masuk ke registry dengan tag versi yang jelas. Build selesai. Pengujian lolos. Artefak tersimpan. Tanggung jawab CI berhenti di situ.

CD dimulai dari registry. CD tidak membangun ulang artefak. Ia menarik artefak yang sama persis yang disimpan CI, lalu men-deploy-nya ke lingkungan target. Tidak ada kompilasi ulang. Tidak ada dependensi yang berbeda. Tidak ada "Saya pikir ini build yang sama."

Pemisahan ini tidak hanya teknis. Ini tentang kepemilikan. CI memiliki kebenaran build. CD memiliki kebenaran deployment. Jika sesuatu rusak di production, Anda melacak kembali ke artefak tepat di registry. Anda tahu versinya, hash commit-nya, timestamp build-nya. Tidak ada tebakan.

Promosi Tanpa Modifikasi

Registry yang baik juga memungkinkan promosi artefak. Promosi adalah proses menandai artefak tertentu sebagai siap untuk lingkungan berikutnya. Anda tidak memodifikasi artefak itu sendiri. Anda menambahkan metadata.

Misalnya, CI Anda menghasilkan artefak yang diberi tag 1.2.3-build.45. Artefak itu berada di registry. Ketika lolos pengujian staging, Anda menambahkan tag: staging. Ketika lolos validasi production, Anda menambahkan tag lain: production. Artefak yang mendasarinya identik. Hanya statusnya yang berubah.

Ini penting karena menjaga jejak audit yang bersih. Anda selalu dapat melihat versi mana yang dipromosikan ke lingkungan mana dan kapan. Tanpa mekanisme ini, tim akhirnya membangun ulang untuk setiap lingkungan, memperkenalkan perbedaan halus antara apa yang diuji dan apa yang berjalan di production.

Apa yang Terjadi Tanpa Registry

Tim yang melewatkan pengaturan registry yang tepat menghadapi masalah yang sama berulang kali:

  • Pengembang saling bertanya build mana yang akan di-deploy.
  • Staging menjalankan versi yang berbeda dari production.
  • Rollback menjadi tebak-tebakan karena tidak ada yang tahu apa yang sebenarnya berjalan sebelumnya.
  • Pemindaian keamanan berjalan pada beberapa build tetapi tidak pada yang lain karena tidak ada inventaris terpusat.
  • Audit kepatuhan berubah menjadi rantai email manual yang mencoba merekonstruksi apa yang di-deploy enam bulan lalu.

Registry menghilangkan semua ini. Ini bukan kemewahan. Ini adalah fondasi yang memungkinkan pipeline yang disiplin.

Daftar Periksa Praktis untuk Menyiapkan Registry Anda

Jika Anda menyiapkan registry untuk pertama kalinya, atau meninjau pengaturan Anda saat ini, berikut adalah daftar periksa singkat:

  • Pilih jenis yang tepat: container registry untuk image, artifact repository untuk biner dan paket. Beberapa alat seperti Harbor atau Artifactory menangani keduanya.
  • Terapkan immutability: setelah artefak disimpan dengan tag versi, jangan izinkan penimpaan. Build baru mendapatkan versi baru.
  • Tetapkan kebijakan retensi: tidak setiap build perlu hidup selamanya. Simpan N build terakhir atau build dari M hari terakhir. Arsipkan atau hapus sisanya.
  • Kontrol akses: pipeline harus memiliki akses tulis. Pengembang dan pipeline CD harus memiliki akses baca. Gunakan peran IAM atau token, bukan kata sandi bersama.
  • Tag promosi secara eksplisit: gunakan metadata atau tag untuk menandai artefak mana yang ada di staging, production, atau di-rollback. Otomatiskan ini di pipeline CD Anda.

Intisari Konkret

Registry bukan sekadar penyimpanan. Ia adalah kontrak antara proses build dan proses deployment Anda. Ia memastikan bahwa apa yang dibangun adalah persis apa yang di-deploy. Ia memberi tim Anda satu tempat untuk melihat ketika sesuatu salah. Ia membuat promosi dapat dilacak dan rollback dapat diandalkan.

Siapkan registry Anda sebelum deployment berikutnya. Diri Anda di masa depan, yang sedang melakukan debug insiden tengah malam, akan berterima kasih.