Merilis tanpa menebak
Sebuah deploy diperlakukan sebagai gerbang, bukan sebagai perintah.
Ringkas dulu
- Apa ini?
- Disiplin yang membuat perubahan produksi bisa dibatalkan dan bisa dibuktikan.
- Mengapa penting?
- Build yang sukses bukan berarti perubahan produksi yang sukses, dan deployment yang selesai bukan berarti diterima publik.
- Bagaimana cara kerjanya?
- Rilis menyebut artefak persis, menyiapkan titik pulih sebelum mengubah apa pun, menjaga jalur terlindungi, dan membuktikan runtime yang benar-benar melayani.
- Contoh konkretnya?
- "Rilis yang terbaru" tidak bisa dibatalkan ke mana pun, karena "terbaru" menunjuk hal yang berbeda setiap kali dibaca.
- Berikutnya baca apa?
- "Adopsi rujukan", untuk melihat disiplin ini pada pekerjaan produksi yang nyata.
Artefak yang persis, bukan "yang terbaru"
Sebuah rilis menyebut rujukan yang persis. Bukan "terbaru", bukan "build sekarang", bukan "yang ada di branch". Semua itu menggambarkan sasaran yang bergerak, dan sasaran yang bergerak tidak bisa dituju kembali maupun ditelaah setelah kejadian.
Build yang sukses juga bukan hal yang sama dengan perubahan produksi yang sukses, dan deployment yang selesai bukan hal yang sama dengan penerimaan publik. Masing-masing adalah klaim terpisah yang butuh buktinya sendiri.
Contoh konkret
Dua orang membaca catatan rilis "sudah dipasang versi terbaru" pada hari yang berbeda akan memasang dua artefak yang berbeda, dan tidak ada satu pun yang bisa dikembalikan dengan pasti. Satu commit yang disebut lengkap menghapus seluruh ambiguitas itu.
Siapkan jalan pulang sebelum mengubah
Titik pulih disiapkan sebelum apa pun diubah, bukan setelah ada yang salah. Menyiapkan pemulihan ketika sistem masih sehat adalah satu-satunya waktu ketika hal itu bisa dilakukan dengan tenang dan diverifikasi.
Rilis yang tidak bisa menyebut ke mana ia akan kembali belum direncanakan, sebaik apa pun perubahannya ditulis.
Jalur yang dilindungi
Sebagian jalur harus selamat melewati rilis secara eksplisit, bukan kebetulan: konten, unggahan, konfigurasi, dan apa pun yang kehilangannya tidak akan terlihat di log build.
Contoh konkret
Folder unggahan pelanggan yang terhapus saat deploy tidak akan memunculkan satu pun pesan error. Build tetap hijau, deployment tetap sukses, dan datanya tetap hilang. Karena itu perlindungannya dinyatakan lebih dulu.
Membuktikan runtime yang benar-benar melayani
Ketika relevan, yang harus dibuktikan adalah runtime yang benar-benar melayani jalur permintaan publik — bukan runtime yang dikonfigurasi, yang diniatkan, atau yang diyakini sedang melayani.
Verifikasi pascarilis adalah bagian dari rilis, bukan tindak lanjut opsional. Sebuah rilis selesai ketika perilaku pelayanannya sudah ditunjukkan, bukan ketika perintah deployment selesai tanpa galat.
Sumber kanonik yang dijelaskan halaman ini
Halaman ini menjelaskan berkas-berkas berikut. Kalau isinya berbeda, berkas itu yang berlaku — bukan tulisan di sini.
docs/product/DEV-WEB-PRODUCT-REQUIREMENTS.mdkernel/core/foundation.contract.jsonschemas/release-evidence.schema.json