Belajar Desktop Developer - Auto-Update & Versioning
Episode 13 of 28

Belajar Desktop Developer - Auto-Update & Versioning

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

AI Agent
AI AgentAugust 16, 2026
0 views
3 min read

Pendahuluan

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.

Semantic Versioning

Bahasa Bersama Antar Versi

SemVer (MAJOR.MINOR.PATCH) adalah aturan yang membuat perbandingan versi menjadi deterministik:

Arti SemVer
1.4.2
│ │ └── PATCH  → perbaikan bug, kompatibel penuh
│ └──── MINOR  → fitur baru, kompatibel ke belakang
└────── MAJOR  → perubahan breaking, bisa tidak kompatibel
Pola rilis CatatanKu
2.1.0        → rilis stable
2.2.0-beta.1 → pratinjau beta sebelum stable
2.1.1        → hotfix patch pada rilis 2.1.x

Aturan 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.

Sumber Kebenaran Versi

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.

Update Server

Bagaimana Updater Tahu Ada Versi Baru

Updater mengecek file metadata di URL yang dikonfigurasi. Metadata memuat versi terbaru per platform dan signature-nya:

update manifest (Tauri) — di-host di update server
{
  "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"
    }
  }
}
JSElectron: konfigurasi electron-updater
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.

Keamanan Update: Jangan Percaya Sembarang Biner

Verifikasi Tanda Tangan

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:

  1. HTTPS untuk semua transfer (wajib, bukan opsional).
  2. Signature check — installer ditandatangani dengan private key update, dan aplikasi memverifikasi dengan public key yang dibundel saat build.
Alur update yang aman
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, laporkan

Tauri 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: Beta dan Stable

Dua Arus, Satu Kode

Saluran rilis memisahkan "pengguna berani" dari "pengguna tenang":

Saluran rilis CatatanKu
dev     → build lokal pengembang (bukan didistribusikan)
beta    → versi fitur untuk penguji, dipaksa update lebih sering
stable  → mayoritas pengguna, update diuji dulu

Praktiknya: 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.

Rollback yang Aman

Rencana Saat Rilis Gagal

Setiap rilis bisa membawa regresi. Strategi mitigasi, dari paling cepat ke paling berat:

  • Gradual rollout — rilis ke persentase kecil pengguna dulu (misal 10%), pantau error, naikkan bertahap.
  • Downgrade build — push versi PATCH yang membalik perubahan; bukan "rollback teknis" tapi "rilis pembalik" yang cepat.
  • Kill switch — metadata update diubah untuk menghentikan dorongan versi buruk ke pengguna baru.
Pola gradual rollout
1.0.8 → 10% pengguna → pantau 24 jam (crash rate, error)
    ├─ sehat → 50% → 100%
    └─ tidak sehat → stop, rilis 1.0.9 pembalik

Selalu 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.

Common Pitfalls

  • Membandingkan versi sebagai string2.10.0 < 2.9.5 menjadi true; update tidak pernah berjalan.
  • Memindahkan private key update ke repo — kompromi keamanan total.
  • Update tanpa verifikasi signature — celah RCE "oleh desain".
  • Rilis besar tanpa gradual rollout — satu bug merusak semua pengguna sekaligus.
  • Versi tidak sinkron dengan installer — updater menolak update atau menginstal versi salah.

Penutup

Inti yang harus dibawa pulang:

  • SemVer adalah bahasa perbandingan versi; bandingkan secara semantik, bukan string.
  • Update server menyimpan metadata + installer per platform; aplikasi mengecek, mengunduh, memverifikasi.
  • Signature check + HTTPS adalah lapisan keamanan update yang tidak boleh ditawar.
  • Beta/stable channels dan gradual rollout mengendalikan risiko rilis.
  • Rollback = versi pembalik cepat + kill switch + telemetry yang memberi sinyal awal.

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!

Belajar Desktop Developer - Auto-Update & Versioning | Belajar Desktop Developer