Mengapa Anda Tidak Boleh Membangun Ulang Artifact Setelah Lolos Pengujian

Bayangkan ini: tim Anda baru saja menghabiskan tiga jam menjalankan pengujian pada sebuah build di lingkungan staging. Semua hijau. Manajer rilis berkata, "Bagus, mari kita build lagi untuk produksi." Seseorang memicu kompilasi baru, mengemasnya, dan melakukan deploy. Satu jam kemudian, produksi mulai memunculkan error yang tidak pernah muncul di staging. Kodenya sama, tetapi artifact-nya berbeda. Anda baru saja kehilangan satu jaminan yang paling penting: apa yang Anda uji bukanlah yang Anda jalankan.

Skenario ini lebih sering terjadi daripada yang diakui oleh sebagian besar tim. Perbaikannya bukanlah alat build yang lebih baik. Ini adalah disiplin yang dimulai saat pipeline Anda berjalan.

Build Sekali, Gunakan di Mana Saja

Aturan pertama manajemen artifact sederhana: build tepat satu kali. Satu artifact itu berjalan melalui setiap lingkungan dari pengembangan hingga produksi. Tidak ada kompilasi ulang. Tidak ada pengemasan ulang. Tidak ada "biarkan saya build ulang dengan flag produksi."

Diagram alur berikut mengilustrasikan bagaimana satu artifact bergerak melalui lingkungan melalui promosi, tidak pernah dibangun ulang:

flowchart TD A[Source Code Commit] --> B[Build Artifact] B --> C[Calculate Checksum] C --> D[Push to Registry] D --> E[Deploy to Dev] E --> F[Run Tests in Dev] F --> G{Tests Pass?} G -- Yes --> H[Promote in Registry] G -- No --> I[Fix Code & Rebuild] H --> J[Deploy to Staging] J --> K[Run Tests in Staging] K --> L{Tests Pass?} L -- Yes --> M[Promote in Registry] L -- No --> I M --> N[Verify Checksum] N --> O[Deploy to Production] O --> P[Production Running] style B fill:#4CAF50,color:#fff style H fill:#FF9800,color:#fff style M fill:#FF9800,color:#fff style N fill:#2196F3,color:#fff

Ini bukan tentang menjadi malas. Ini tentang kepastian. Saat Anda membangun ulang, Anda memperkenalkan variabel. Mungkin server CI memiliki status cache yang berbeda. Mungkin dependensi diperbarui di antara build. Mungkin agen build memiliki versi library yang sedikit berbeda. Salah satu dari ini dapat menghasilkan biner yang berperilaku berbeda dari yang Anda uji.

Artifact yang sama yang lulus semua pemeriksaan di staging harus menjadi artifact yang sama yang berjalan di produksi. Jika Anda tidak dapat menjamin itu, Anda tidak dapat mempercayai pengujian Anda.

Berikan Setiap Artifact Identitas yang Dapat Dilacak

Anda harus dapat menjawab satu pertanyaan tentang artifact apa pun: dari mana asalnya? Itu berarti setiap artifact harus membawa identitas yang menghubungkan kembali ke kode sumber yang tepat, pipeline run yang tepat, dan momen yang tepat saat dibuat.

Otomatiskan ini. Jangan pernah biarkan manusia menetapkan nomor versi. Pipeline Anda harus menghasilkan ID build yang menggabungkan:

  • Stempel waktu kapan build dimulai
  • Nomor build berurutan
  • Hash commit Git

Dengan kombinasi ini, Anda dapat mengambil artifact apa pun dari registry Anda dan mengetahui dengan tepat commit mana yang menghasilkannya, pipeline mana yang membangunnya, dan kapan. Tanpa tebakan. Tanpa "saya pikir ini dari rilis minggu lalu."

Tempatkan Artifact di Registry, Bukan di Server

Saat build selesai, artifact harus segera meninggalkan server CI. Artifact tidak boleh duduk di workspace, di laptop pengembang, atau di folder jaringan bersama. Ia langsung menuju ke registry artifact pusat.

Registry menjadi sumber kebenaran tunggal. Tim, pipeline, atau lingkungan mana pun tahu persis di mana menemukan artifact yang mereka butuhkan. Tanpa registry, Anda akan kesulitan menjawab pertanyaan dasar seperti "Versi artifact mana yang sedang berjalan di produksi?" atau "Bisakah saya mereproduksi build yang tepat dari rilis bulan lalu?"

Registry juga memberi Anda kendali. Anda dapat mengatur izin, menerapkan kebijakan retensi, dan melacak siapa yang mengakses apa. Kemampuan ini menjadi kritis saat tim Anda tumbuh dan banyak pipeline mulai mengonsumsi artifact.

Promosikan, Jangan Bangun Ulang

Setelah artifact lulus semua pengujian di staging, pipeline tidak boleh membangunnya ulang untuk produksi. Sebaliknya, ia mempromosikan artifact yang sudah ada. Promosi berarti mengubah metadata: memperbarui label, memindahkan artifact ke folder yang berbeda, atau menandainya sebagai "siap-produksi" di registry.

File itu sendiri tetap identik. Byte yang sama yang berjalan melalui setiap pengujian adalah byte yang sama yang akan berjalan di produksi. Ini adalah inti dari deployment yang dapat direproduksi.

Tetapi bagaimana Anda tahu artifact tidak rusak atau dirusak antara pengujian dan promosi? Di situlah verifikasi berperan.

Verifikasi Sebelum Anda Percaya

Sebelum artifact pindah ke produksi, pipeline Anda harus memverifikasi integritasnya. Metode yang paling umum adalah verifikasi checksum.

Saat build selesai, pipeline menghitung checksum artifact, biasanya menggunakan SHA256. Checksum ini disimpan bersama metadata artifact. Sebelum promosi, pipeline menghitung ulang checksum dan membandingkannya dengan nilai yang disimpan. Jika tidak cocok, ada yang salah. File mungkin rusak selama penyimpanan, atau seseorang mungkin telah mengubah artifact tanpa izin.

Untuk jaminan yang lebih kuat, gunakan penandatanganan. Pipeline menandatangani artifact dengan kunci privat tim. Selama promosi, registry memverifikasi tanda tangan. Penandatanganan melakukan lebih dari sekadar memeriksa integritas. Ini membuktikan bahwa artifact benar-benar dibangun oleh pipeline resmi Anda, bukan oleh orang lain yang mendapatkan akses ke registry Anda. Ini penting ketika beberapa tim berbagi registry yang sama atau ketika artifact diambil dari sumber eksternal.

Jaring Pengaman

Keempat disiplin ini bekerja sama sebagai jaring pengaman:

  • Build sekali memastikan konsistensi di seluruh lingkungan.
  • Versioning otomatis memastikan ketertelusuran kembali ke kode sumber.
  • Registry pusat memastikan aksesibilitas bagi semua konsumen.
  • Promosi tanpa rebuild memastikan reprodusibilitas.
  • Verifikasi memastikan kepercayaan pada integritas artifact.

Jika salah satu dari ini lemah, pipeline Anda memiliki lubang. Anda mungkin memiliki pengaturan CI/CD yang indah di atas kertas, tetapi dalam praktiknya, Anda hanya berjarak satu rebuild dari insiden produksi yang tidak pernah terdeteksi oleh pengujian Anda.

Daftar Periksa Cepat untuk Pipeline Anda

Jika Anda menyiapkan atau meninjau manajemen artifact, jalankan ini:

  • Apakah pipeline membangun setiap artifact tepat satu kali per commit?
  • Apakah setiap artifact memiliki pengidentifikasi versi otomatis yang dapat dilacak?
  • Apakah artifact didorong ke registry pusat segera setelah build?
  • Apakah pipeline mempromosikan artifact dengan mengubah metadata, bukan dengan membangun ulang?
  • Apakah verifikasi checksum atau tanda tangan dilakukan sebelum promosi ke produksi?

Jika Anda menjawab tidak untuk salah satu dari ini, Anda memiliki celah yang layak diperbaiki sebelum rilis Anda berikutnya.

Apa Artinya Ini untuk Tim Anda

Ketika tim Anda secara konsisten mengikuti disiplin ini, pipeline menjadi dapat diprediksi. Anda berhenti bertanya-tanya apakah produksi menjalankan kode yang sama yang lulus pengujian. Anda berhenti berburu perbedaan antara build. Anda mulai mempercayai proses deployment Anda.

Dan setelah kepercayaan itu terbentuk, Anda dapat fokus pada lapisan berikutnya: bagaimana artifact mengalir melalui lingkungan, siapa yang memiliki wewenang untuk mempromosikan, dan bagaimana kebijakan ditegakkan secara otomatis. Tapi tidak ada yang berarti jika Anda tidak dapat mempercayai artifact itu sendiri. Build sekali. Promosikan, jangan rebuild. Verifikasi sebelum Anda deploy. Segala sesuatu yang lain dibangun di atas fondasi itu.