Mengapa Anda Tidak Boleh Pernah Melakukan Build Ulang untuk Produksi

Beberapa minggu lalu, sebuah tim yang saya dampingi mengalami masalah aneh. Lingkungan staging mereka lulus semua pengujian. Tim QA memberikan persetujuan. Product owner memberi lampu hijau. Namun, ketika mereka deploy ke produksi, pengguna mulai melihat error yang tidak pernah muncul selama pengujian.

Tim menghabiskan dua hari untuk debugging. Mereka membandingkan file konfigurasi, memeriksa variabel lingkungan, dan meninjau perubahan kode. Semuanya tampak identik. Akhirnya, seseorang menyadari timestamp build berbeda. Artefak yang berjalan di produksi bukanlah artefak yang sama yang lulus semua pengujian di staging.

Ini adalah cerita yang terulang di berbagai tim setiap hari. Akar masalahnya hampir selalu sama: di suatu tempat antara staging dan produksi, seseorang memutuskan untuk membangun ulang aplikasi, alih-alih mempromosikan artefak yang sudah ada.

Dua Jalur: Rebuild vs. Promote

Setiap pipeline pengiriman perangkat lunak memiliki banyak lingkungan. Lingkungan development untuk mencoba fitur baru. Staging untuk verifikasi oleh QA atau product owner. Produksi tempat pengguna nyata berinteraksi dengan aplikasi Anda.

Ketika Anda perlu memindahkan artefak dari satu lingkungan ke lingkungan berikutnya, Anda memiliki dua pilihan.

Rebuild berarti mengambil kode sumber dari commit tertentu dan menjalankan proses build lagi untuk lingkungan target. Pipeline melakukan checkout kode, mengunduh dependensi, mengompilasi aplikasi, dan menghasilkan artefak baru.

Diagram alir berikut mengilustrasikan kedua jalur beserta hasilnya:

flowchart TD A[Mulai: Perlu deploy ke produksi] --> B{Pilih jalur} B --> C[Rebuild] B --> D[Promote] C --> E[Checkout kode sumber] E --> F[Unduh dependensi] F --> G[Kompilasi aplikasi] G --> H[Artefak baru dengan checksum & timestamp baru] H --> I[Deploy ke produksi] I --> J[Resiko: berbeda dari artefak yang diuji] D --> K[Artefak yang sudah ada di registry] K --> L[Tandai sebagai disetujui untuk produksi] L --> M[Deploy byte yang sama ke produksi] M --> N[Kepastian: cocok dengan artefak yang diuji]

Promote berarti mengambil artefak yang sudah ada di registry Anda, yang sudah dibangun dan diverifikasi di lingkungan sebelumnya, dan menandainya sebagai disetujui untuk lingkungan berikutnya. Tidak ada build baru. Tidak ada kompilasi baru. Hanya perubahan metadata yang menyatakan "artefak ini sekarang diizinkan di produksi."

Kedua pendekatan ini terdengar mirip, tetapi menghasilkan hasil yang sangat berbeda.

Risiko Tersembunyi dari Rebuild

Ketika Anda melakukan rebuild untuk produksi, Anda menciptakan artefak baru. Artefak tersebut memiliki ID build yang berbeda. Timestamp yang berbeda. Dan yang kritis, dependensi yang diunduh selama build baru ini mungkin berbeda dari yang digunakan saat build staging.

Bayangkan apa yang terjadi ketika proses build Anda menjalankan npm install, pip install, atau go mod download. Perintah-perintah ini menjangkau repositori jarak jauh untuk mengambil paket. Jika maintainer paket mendorong pembaruan kecil di antara build staging dan build produksi Anda, artefak produksi Anda akan menyertakan pembaruan tersebut. Meskipun perubahan tersebut secara teknis kompatibel ke belakang, perubahan itu tetap memperkenalkan perbedaan antara apa yang Anda uji dan apa yang Anda jalankan di produksi.

Risiko yang sama berlaku untuk toolchain Anda. Jika sistem CI Anda memperbarui versi kompiler, base image, atau alat build di antara build, keluarannya dapat berubah dengan cara yang halus. Kode yang terkompilasi dengan baik selama build staging mungkin menghasilkan instruksi mesin yang berbeda selama build produksi.

Anda kehilangan kepastian bahwa apa yang diuji adalah apa yang berjalan di produksi. Anda beralih dari keyakinan menjadi harapan.

Mengapa Promote Bekerja Lebih Baik

Promosi menghilangkan ketidakpastian ini. Artefak dibangun sekali, disimpan di registry Anda, dan diverifikasi di staging. Ketika lulus semua pemeriksaan, Anda mempromosikannya ke produksi dengan memperbarui metadata atau tag-nya. Tidak ada kompilasi baru. Tidak ada unduhan dependensi baru. Byte yang persis sama yang berjalan di staging sekarang berjalan di produksi.

Dalam praktiknya, promosi biasanya bekerja melalui tagging. Di container registry, Anda mungkin memiliki image yang diberi tag staging. Setelah verifikasi, Anda menambahkan tag production ke image yang sama. Image itu sendiri tidak berubah. Hanya labelnya yang berubah. Sistem deploy Anda memantau tag production dan menarik image saat tag tersebut muncul.

Pendekatan ini juga menyederhanakan rollback. Jika versi baru menyebabkan masalah di produksi, Anda cukup mengarahkan kembali ke artefak yang dipromosikan sebelumnya. Anda tidak perlu membangun ulang dari commit lama, berharap dependensi dan toolchain dari tiga bulan lalu masih tersedia. Artefak lama sudah ada di registry Anda, persis seperti saat dipromosikan sebelumnya.

Verifikasi Tetap Dilakukan Sebelum Promosi

Promosi tidak berarti melewatkan verifikasi. Sebelum artefak berpindah dari staging ke produksi, artefak harus lulus serangkaian pengujian yang telah ditentukan. Pengujian unit, pengujian integrasi, dan pemeriksaan khusus lingkungan apa pun yang sesuai untuk aplikasi Anda. Pengujian ini dijalankan terhadap artefak di staging. Jika lulus, artefak dipromosikan. Jika gagal, artefak tetap di staging, dan tim memperbaiki kode sumber, membangun ulang, dan memulai proses verifikasi lagi.

Perbedaan utamanya adalah verifikasi dan promosi menggunakan artefak yang sama. Anda tidak menguji satu versi dan men-deploy versi lainnya.

Kapan Rebuild Mungkin Diperlukan

Ada kasus yang sah di mana rebuild adalah pilihan yang tepat. Jika artefak Anda menyertakan konfigurasi khusus lingkungan yang harus disematkan ke dalam build, Anda mungkin memerlukan build terpisah untuk setiap lingkungan. Jika persyaratan kepatuhan Anda menuntut agar artefak produksi dibangun di pipeline terpisah yang lebih aman, Anda mungkin harus melakukan rebuild.

Tetapi kasus-kasus ini adalah pengecualian, bukan aturan. Sebagian besar tim dapat memisahkan konfigurasi dari kode. Sebagian besar persyaratan kepatuhan dapat dipenuhi dengan menandatangani artefak setelah promosi, bukan dengan membangun ulang. Jika Anda sering melakukan rebuild untuk produksi, tanyakan apakah alasannya adalah kebutuhan teknis atau sekadar kebiasaan.

Daftar Periksa Praktis untuk Promosi Artefak

Sebelum Anda menyiapkan alur kerja promosi, verifikasi poin-poin ini:

  • Proses build Anda menghasilkan satu artefak yang berfungsi di semua lingkungan
  • Registry Anda mendukung pembaruan tag atau metadata tanpa mengunggah ulang
  • Sistem deploy Anda dapat memantau perubahan tag dan memicu deployment
  • Proses rollback Anda merujuk ke artefak yang dipromosikan sebelumnya, bukan ke commit lama
  • Tim Anda memahami bahwa "promosi" berarti mengubah metadata, bukan membangun ulang

Intisari Konkret

Keputusan antara rebuild dan promote bermuara pada satu pertanyaan: apakah Anda ingin yakin bahwa apa yang Anda uji adalah apa yang Anda deploy, atau Anda ingin berharap bahwa build baru menghasilkan hasil yang sama?

Promosi memberi Anda kepastian. Rebuild memberi Anda harapan. Di produksi, kepastian lebih penting daripada harapan. Bangun sekali, verifikasi secara menyeluruh, promosikan dengan percaya diri. Pengguna Anda akan berterima kasih, dan sesi debugging Anda akan lebih singkat.