Menyiapkan siklus update profesional untuk CatatanKu: semantic versioning, saluran rilis stable/beta, update server, validasi update untuk keamanan, dan strategi rollback agar rilis buruk tidak merugikan pengguna

Di episode 12 kita mengemas CatatanKu menjadi installer dan menandatanganinya. Namun installer yang diunduh sekali itu langsung basi: bug ditemukan, fitur ditambahkan, keamanan di-tambal. Aplikasi desktop yang sehat punya jalur update yang membawa setiap pengguna ke versi terbaru secara otomatis — tanpa pengguna perlu mengunduh ulang manual dari website.
Auto-update terdengar sederhana ("download versi baru, jalankan installer"), tetapi di baliknya ada keputusan berbahaya: bagaimana versi dibandingkan, bagaimana pembaruan diverifikasi keasliannya, bagaimana saluran beta/stable dibedakan, dan apa yang terjadi saat rilis baru ternyata buruk. Episode ini membangun sistem update CatatanKu yang aman dan dapat di-rollback.
SemVer (MAJOR.MINOR.PATCH) adalah aturan yang membuat perbandingan versi menjadi deterministik:
1.4.2
│ │ └── PATCH → perbaikan bug, kompatibel penuh
│ └──── MINOR → fitur baru, kompatibel ke belakang
└────── MAJOR → perubahan breaking, bisa tidak kompatibel2.1.0 → rilis stable
2.2.0-beta.1 → pratinjau beta sebelum stable
2.1.1 → hotfix patch pada rilis 2.1.xAturan emas auto-update: bandingkan versi secara semantik, bukan string. 2.10.0 harus dianggap lebih baru dari 2.9.5 (perbandingan string akan salah). Library updater (Tauri updater, Electron electron-updater) sudah menangani ini — kalian tidak perlu menulis sendiri.
Versi aplikasi didefinisikan sekali di file konfigurasi (package.json, Cargo.toml, pubspec.yaml), lalu dipakai bersama oleh installer, updater, dan metadata OS. Kunci konsistensi: selalu rilis dari tag git + CI (episode 17), bukan mengetik versi manual di banyak tempat.
Updater mengecek file metadata di URL yang dikonfigurasi. Metadata memuat versi terbaru per platform dan signature-nya:
{
"version": "2.1.0",
"notes": "Perbaikan sinkronisasi dan pencarian FTS",
"pub_date": "2026-08-16T08:00:00Z",
"platforms": {
"windows-x86_64": {
"signature": "dW50cnVzdGVkIG...",
"url": "https://dl.catatanku.app/windows/2.1.0/setup.exe"
},
"linux-x86_64": {
"signature": "dW50cnVzdGVkIG...",
"url": "https://dl.catatanku.app/linux/2.1.0/appimage"
},
"darwin-x86_64": {
"signature": "dW50cnVzdGVkIG...",
"url": "https://dl.catatanku.app/macos/2.1.0/app.dmg"
}
}
}const { autoUpdater } = require("electron-updater");
autoUpdater.setFeedURL({
provider: "generic",
url: "https://dl.catatanku.app/update/",
});
autoUpdater.on("update-downloaded", () => {
autoUpdater.quitAndInstall();
});
setInterval(() => autoUpdater.checkForUpdates(), 4 * 60 * 60 * 1000);Flow yang dihasilkan: aplikasi mengecek metadata (bisa setiap 4 jam atau saat startup), membandingkan versi, mengunduh installer baru jika ada, memverifikasi signature, dan menginstal — dengan konfirmasi pengguna atau otomatis.
Kerentanan terbesar auto-update adalah mengunduh dan menjalankan biner dari server tanpa verifikasi. Serangan man-in-the-middle atau server yang diretas bisa mendorong malware "sebagai update". Solusinya dua lapis:
Server mendorong: setup.exe + signature(setup.exe, private_key)
Aplikasi memegang: public_key (dibundel saat build)
Aplikasi memverifikasi: signature_valid(setup.exe, public_key)?
└─ valid → install invalid → tolak, laporkanTauri updater dan electron-updater mendukung pola ini bawaan. Jangan pernah mematikannya. Private key update harus disimpan di secret manager CI — bocor berarti penyerang bisa menandatangani malware yang disamarkan sebagai update aplikasi kalian.
Warning
Update yang tidak memverifikasi signature setara dengan memberi siapa pun kunci rumah kalian. Private key update tidak boleh berada di repo, laptop developer, atau server tanpa enkripsi — hanya di secret manager CI/CD (episode 17), dan signing dilakukan otomatis di pipeline, bukan manual.
Saluran rilis memisahkan "pengguna berani" dari "pengguna tenang":
dev → build lokal pengembang (bukan didistribusikan)
beta → versi fitur untuk penguji, dipaksa update lebih sering
stable → mayoritas pengguna, update diuji duluPraktiknya: release pipeline membangun dua artfak dari satu tag — 2.2.0-beta.1 untuk channel beta, lalu 2.2.0 untuk stable setelah masa uji. Pengguna memilih channel di pengaturan; appId sama, jadi peralihan channel tidak merusak data.
Setiap rilis bisa membawa regresi. Strategi mitigasi, dari paling cepat ke paling berat:
1.0.8 → 10% pengguna → pantau 24 jam (crash rate, error)
├─ sehat → 50% → 100%
└─ tidak sehat → stop, rilis 1.0.9 pembalikSelalu simpan versi terakhir yang diketahui baik di update server, dan pastikan telemetry (episode 20) memberi sinyal lebih awal: crash rate naik, startup gagal, atau error terkait fitur baru.
2.10.0 < 2.9.5 menjadi true; update tidak pernah berjalan.Inti yang harus dibawa pulang:
Di episode 14 selanjutnya kita mengeraskan keamanan CatatanKu: security desktop — secrets, sandboxing, dan secure IPC — fondasi yang melindungi pengguna dan reputasi aplikasi. Sampai jumpa di episode 14!