Rilis baru. Hentikan node. Ganti biner. Lalu cari tahu apakah yang Anda unduh ternyata benar semuanya.
Itulah jenis rutinitas pemeliharaan yang saya asumsikan operator Dusk hanya perlu mengelolanya dengan cermat. Namun alur terbaru penginstal node mengubah satu detail yang menurut saya lebih penting daripada yang terdengar. Versi 0.5.22 memperkuat upgrade agar artefak penggantian ditahap (staged) dan diverifikasi sebelum file live diganti. Prosedur upgrade Dusk mengikuti urutan yang sama: penginstal mengunduh biner Rusk dan wallet yang didukung, memeriksanya, dan hanya setelah itu menghentikan layanan Rusk yang sedang berjalan. Ia juga mempertahankan status rantai (chain state) operator, kunci konsensus, dan override layanan yang disengaja, alih-alih memperlakukan upgrade seperti pemasangan node baru.
Layanannya tetap dalam kondisi berhenti setelahnya agar operator dapat meninjau konfigurasi yang dibuat ulang, memulai Rusk secara sengaja, dan mengonfirmasi rekan (peers) serta kemajuan tinggi blok sebelum menyatakan pekerjaan selesai.
Itu adalah tonggak operasional kecil namun berguna.
Jendela upgrade sekarang dimulai setelah penggantinya siap, bukan saat operator masih mencari tahu apakah itu bisa digunakan.
Untuk infrastruktur yang seharusnya tetap tersedia, urutan tersebut nilainya lebih besar daripada satu perintah yang lebih nyaman.
@Dusk $DUSK #dusk