Pembaruan Otomatis Aplikasi Electron: Panduan Praktis 2026

Kamu telah mengirimkan build Electron, halaman rilis sudah aktif, dan tiket dukungan pertama datang sebelum mesin kopi selesai. Salah satu pengguna mengatakan aplikasi tidak menemukan update. Pengguna lain mengunduhnya tetapi tidak bisa menginstalnya. Satu lagi masih menjalankan versi lama dengan alur autentikasi yang rusak, sementara log kamu menunjukkan tidak ada informasi yang berguna.

Itu adalah kenyataan yang tidak nyaman dari Auto Update Aplikasi Electron. Pengatur update API hanya salah satu komponen. Rilis produksi juga bergantung pada tanda tangan platform, kebijakan transportasi, manifest, hosting, event kehidupan, observabilitas, kontrol perluasan, dan jalur rollback. Anggap salah satu dari itu sebagai opsional dan patch rutin bisa menjadi insiden malam hari.

Isi Kandungan

• Kasus Update Malam 2 yang Membuat Panduan Ini
• Pilih Jalur Pengatur Update Electron yang Tepat
• Mengimplementasikan Alur Auto-Update di Proses Utama
  • Konfigurasi target publikasi terlebih dahulu
  • Jadwalkan periksa dan terapkan event kehidupan
  • Tetapkan renderer informasi tanpa menghalangi pekerjaan
• Wiring CI/CD untuk Rilis Tanda Tangan dan Manifest
  • Jadikan tanda tangan eksplisit di CI
• Rollouts, Saluran, dan Strategi Rollback
  • Pakai kelompok sebelum paparan luas
• Menggunakan Auto-Update sebagai Kontrol Keamanan
  • Lindungi metadata dengan hati-hati seperti biner
• Buku dan Daftar Periksa Pembaruan Produksi
  • Gates pra-rilis
  • Canary dan roll-out penuh
  • Tanggapi insiden

Insiden Pembaruan Pagi Pukul 2 yang Membuat Ini Panduan

Rilis itu lolos CI dan terlihat biasa. Pada akhir pekan, seorang pengembang menerbitkan bangunan Elektron yang tidak ditandatangani, dan pekerja publikasi mengunggah cukup aset untuk membuat rilis tampak lengkap. Aplikasi diluncurkan dalam pengujian, tetapi tidak ada yang menguji jalur pembaruan dari bangunan produksi yang terpasang.

Di pukul 2:08 pagi, PagerDuty mengingatkan insinyur yang bertugas. Aliran autentikasi baru gagal untuk sebagian armada, dan pengguna yang menerima update tidak dapat menyelesaikan proses sign-in. Pengguna lain tetap menggunakan versi sebelumnya karena pembaruan tidak dapat memverifikasi atau menginstal artefak. Beberapa pelanggan memiliki rilis yang rusak, sementara armada lainnya menjalankan versi yang berbeda tanpa penjelasan yang jelas.

Penelitian kemudian mengikuti lima pemeriksaan:

1. Pemeriksaan sumber rilis. Binary ada, tetapi metadata yang diharapkan tidak secara jelas menetapkan klien mana yang harus menerima update. Manifest adalah kontrak antara pipa rilis dan klien yang terinstal, bukan detail unggahan yang opsional.
2. Pemeriksaan tanda tangan. Rilis tidak ditandatangani dengan benar, sehingga verifikasi gagal pada platform yang terpengaruh. Tanda tangan harus menghambat publikasi ketika tidak ada atau tidak valid.
3. Pemeriksaan log klien. Error pembaruan tidak pernah mencapai telemetri pusat. Aplikasi menelan event dan terus berjalan, meninggalkan tim tanpa bukti yang dapat diandalkan.
4. Pemeriksaan kontrol perluasan. Tidak ada saluran internal atau kohort yang dipersiapkan. Setiap klien yang layak menggunakan sumber yang sama, sehingga gagalnya menyebar tanpa titik pengamanan.
5. Pencarian untuk rollback. Tim tidak memiliki prosedur yang telah diuji untuk mempublikasikan versi sebelumnya atau mengarahkan klien menjauhi rilis yang rusak.

Referensi resmi Electron menjelaskan batasan platform dengan jelas. Tidak ada dukungan otomatis pembaruan bawaan di Linux.dan permintaan pembaruan macOS harus memenuhi Keperluan Keamanan Transport AplikasiDokumentasi juga mengidentifikasi tanda tangan sebagai syarat untuk pembaruan macOS yang dapat diandalkan dan verifikasi rilis. Dokumentasi Otomatisasi Electron Mengatur batasan API, sementara sistem rilis harus menegakkan kontrol operasional di sekitar.

Pelajaran postmortem: Pengatur ulang yang tidak dapat menjelaskan apa yang terjadi adalah upaya instalasi jarak jauh dengan telemetri yang hilang.

The cost extended beyond engineering time. Customers lost confidence in the desktop client, support had to explain inconsistent behavior, and the team spent the next workday rebuilding a release process that should have existed before the incident.

Pembaruan otomatis Pembaruan ElectronPenandatanganan adalah pintu keluar rilis, manifest menentukan kontrak klien, saluran peluncuran membatasi paparan, dan rollback tetap menjadi jalur yang telah diuji daripada penemuan darurat.

Pilih Jalur Pembaruan Electron yang Tepat

Pada pukul 2 pagi, pilihan pembaruan yang salah menjadi masalah operasional. Pembaruan biner asli harus menangani penandatanganan, manifest, pemasang, dan rollback. Perubahan JavaScript atau CSS renderer hanya mengikuti jalur yang berbeda. Keterbatasan hosting juga berperan: proyek kecil yang dihosting oleh GitHub tidak memerlukan kontrol rilis yang sama seperti layanan distribusi perusahaan.

Untuk proyek yang menggunakan electron-builder dengan publikasi artifact yang ditandatangani, electron-updater biasanya merupakan pilihan default yang praktis. Ecosystemnya mencakup target publikasi, manifest rilis, download artifact, dan instalasi pada peluncuran berikutnya. Ia mendukung beberapa model hosting, tetapi tim Anda masih bertanggung jawab atas penandatanganan, ketersediaan feed, kebijakan saluran, kontrol peluncuran, dan pemantauan. Pembaruan Electron untuk __CAPGO_KEEP_0__ Integrasi pembaruan Electron untuk Capgo Pertinennya ini saat mengevaluasi model pengiriman campuran untuk bundle layer web bersamaan dengan rilis native.

update-electron-app suits teams that want a small integration around GitHub Releases. It checks at startup and then on a recurring interval, which keeps the setup simple but leaves less room for advanced channel selection, staged traffic, and custom rollback rules. The package is reasonable for a small release process, provided GitHub Releases and its availability match your operational requirements.

Jika perlu, gunakan layanan khusus seperti Hazel, Nuts, atau feed internal ketika perlu otorisasi rilis, target penyewa, catatan audit, atau aturan pengiriman yang diatur. Namun, hal ini memerlukan biaya implementasi. Pertukaran adalah kepemilikan yang berkelanjutan. Tim Anda harus mendefinisikan semantik manifest, melindungi kunci tanda tangan, menjaga kompatibilitas klien, dan menguji download gagal, rilis yang ditolak, dan perilaku rollback.

Pembaruan hidup dapat mengirimkan perubahan renderer tanpa membangun shell native kembali. Mereka tidak menggantikan pembaruan biner ketika ada perubahan Electron, modul native, izin, atau perilaku pemasang. Gunakan electron-updater kecuali Anda memerlukan logika pengeluaran khusus. Jika logika khusus diperlukan, bangun sekitar konvensi manifest dan artefak yang sudah ada daripada menciptakan kembali perilaku download dan pembaruan diferensial. Jalur yang dapat diandalkan adalah jalur yang tim Anda dapat amati, tahapkan, dan balikkan di bawah tekanan.

Mengimplementasikan Alur Pembaruan Otomatis di Proses Utama

Proses utama harus mengelola cek pembaruan dan instalasi. Renderer dapat menampilkan status, tetapi tidak boleh menentukan apakah pembaruan eksekutif dapat dipercaya atau kapan aplikasi keluar.

Konfigurasi target publik terlebih dahulu

Konfigurasi minimal electron-builder mungkin terlihat seperti ini:

{
  "build": {
    "appId": "com.example.desktop",
    "publish": [
      {
        "provider": "s3",
        "bucket": "example-electron-releases",
        "channel": "stable"
      }
    ],
    "nsis": {
      "oneClick": false,
      "allowToChangeInstallationDirectory": true
    }
  }
}

Jaga pemasaran beta dan stabil terpisah. Suatu saluran adalah kebijakan rilis, bukan label di UI. Setiap saluran harus menyelesaikan kebenaran tanda tangan dan manifest yang tepat.

Jadwalkan pengecekan dan terbukakan acara kehidupan

Panggilan checkForUpdates() Hanya panggilan selama startup adalah kesalahan produksi umum. Seorang pengguna dapat meninggalkan aplikasi terbuka selama hari-hari, sehingga proses utama membutuhkan interval yang dikendalikan dan strategi ulang yang menghormati operasi offline.

const { app, BrowserWindow, ipcMain } = require('electron');
const { autoUpdater } = require('electron-updater');

let mainWindow;
let isQuitting = false;
let retryDelay = 60 * 1000;

function sendUpdateStatus(status, payload = {}) {
  if (mainWindow && !mainWindow.isDestroyed()) {
    mainWindow.webContents.send('update-status', { status, ...payload });
  }
}

function scheduleUpdateCheck() {
  setTimeout(async () => {
    try {
      await autoUpdater.checkForUpdates();
      retryDelay = 60 * 1000;
    } catch (error) {
      sendUpdateStatus('error', { message: error.message });
      retryDelay = Math.min(retryDelay * 2, 30 * 60 * 1000);
    }
    scheduleUpdateCheck();
  }, retryDelay);
}

app.whenReady().then(() => {
  mainWindow = new BrowserWindow({
    webPreferences: {
      preload: require('path').join(__dirname, 'preload.js')
    }
  });

  autoUpdater.autoDownload = true;
  autoUpdater.autoInstallOnAppQuit = false;

  autoUpdater.on('checking-for-update', () => {
    sendUpdateStatus('checking');
  });

  autoUpdater.on('update-available', info => {
    sendUpdateStatus('available', { version: info.version });
  });

  autoUpdater.on('download-progress', progress => {
    sendUpdateStatus('progress', { percent: progress.percent });
  });

  autoUpdater.on('update-downloaded', info => {
    sendUpdateStatus('downloaded', { version: info.version });
  });

  autoUpdater.on('error', error => {
    sendUpdateStatus('error', { message: error.message });
  });

  autoUpdater.checkForUpdates().catch(error => {
    sendUpdateStatus('error', { message: error.message });
  });

  scheduleUpdateCheck();
});

ipcMain.handle('install-update', () => {
  isQuitting = true;
  autoUpdater.quitAndInstall(false, true);
});

app.on('before-quit', event => {
  if (!isQuitting) {
    return;
  }
});

Perilaku update yang tepat berbeda-beda tergantung pada platform dan pengaturan pengemasan, jadi tes dari artefak yang terpasang daripada mode pengembangan. Dokumentasi Electron juga menyebutkan kekhawatiran waktu startup pada Windows, termasuk kasus Squirrel pertama kali. Jangan panggil pengecekan update sebelum aplikasi telah menyelesaikan inisialisasi spesifik platform yang dibutuhkan.

Jaga informasi renderer tanpa menghalangi pekerjaan

Jembatan preload harus membuka akses yang sempit API:

const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('updates', {
  onStatus(callback) {
    ipcRenderer.on('update-status', (_event, status) => callback(status));
  },
  install() {
    return ipcRenderer.invoke('install-update');
  }
});

Indikator kemajuan renderer sisi dapat tetap sederhana:

window.updates.onStatus(status => {
  const progress = document.querySelector('#update-progress');
  const message = document.querySelector('#update-message');

  if (status.status === 'progress') {
    progress.hidden = false;
    progress.value = status.percent;
    message.textContent = `Downloading update, ${Math.round(status.percent)}%`;
  }

  if (status.status === 'downloaded') {
    message.textContent = `Version ${status.version} is ready to install`;
  }

  if (status.status === 'error') {
    message.textContent = 'The update could not be downloaded. We will retry later.';
  }
});

Jaga instalasi di belakang persetujuan pengguna di produksi kecuali aplikasi Anda memiliki alasan kuat untuk restart segera. Atur isQuitting flag sebelum quitAndInstall(), karena pengaturan penutup jendela normal dapat mencegah installer mengambil alih.

Dua kegagalan layak diuji secara eksplisit. Pertama, klien yang sudah berjalan harus memanggil checkForUpdates() pada jadwal, bukan hanya pada peluncuran. Kedua, error event harus mencapai log dan telemetri. Jika aplikasi menelaninya tanpa melaporkan, alur penyelesaian masalah aplikasi dimulai dengan spekulasi bukan bukti.

Wiring CI/CD untuk Rilis Tanda Tangan dan Manifest

Alur rilis adalah sumber kebenaran untuk apa yang diinstal oleh pengguna. Bangun lokal yang berhasil pada satu mesin pengembang tidak membuktikan bahwa file biner yang diterbitkan, manifest, tanda tangan, dan saluran semua menggambarkan rilis yang sama.

Model publikasi Electron-builder mengharapkan metadata rilis dan target pembaruan untuk berjalan bersama. Untuk banyak konfigurasi, itu berarti artefak seperti latest.yml untuk Windows dan latest-mac.yml Untuk macOS, bersamaan dengan paket platform khusus dan file blockmap. Kurangnya manifest dapat membuat sebuah biner yang valid sepenuhnya tidak terdeteksi oleh klien.

Buat tanda tangan eksplisit dalam CI

Gaya pola GitHub Actions yang sederhana adalah seperti ini:

name: release

on:
  push:
    tags:
      - "v*"

jobs:
  build:
    strategy:
      matrix:
        os: [macos-latest, windows-latest]
    runs-on: ${{ matrix.os }}

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 24
          cache: npm

      - run: npm ci
      - run: npm run test
      - run: npm run build

      - name: Build and publish
        shell: bash
        env:
          CSC_LINK: ${{ secrets.CSC_LINK }}
          CSC_KEY_PASSWORD: ${{ secrets.CSC_KEY_PASSWORD }}
          WIN_CSC_LINK: ${{ secrets.WIN_CSC_LINK }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        run: npx electron-builder --publish always

Gunakan rahasia spesifik platform dan simpan bahan tanda tangan di luar repository. Gagal tanda tangan harus menghentikan pekerjaan, bukan menghasilkan fallback tidak tanda tangan yang seseorang unggah secara manual.

Konfigurasi publik harus mengidentifikasi penyedia dan saluran secara konsisten:

{
  "build": {
    "publish": {
      "provider": "s3",
      "bucket": "example-electron-releases",
      "channel": "stable",
      "publishAutoUpdate": true,
      "updaterCacheDirName": "example-desktop-updater"
    }
  }
}

Before publication, gate the job on the package version, tag, commit SHA, and smoke-test result. After publication, verify that the feed contains the expected manifest and that the manifest points to the exact artifact generated by that job. The Petunjuk Pengaturan Integrasi Terus Menerus Bermanfaat ketika Anda formalisasi periksaan-periksaan tersebut, dan tim yang membandingkan pipeline orchestrasi juga dapat memperoleh manfaat dari memahami Kapan Menggunakan Jenkins dan Ansible Bersama-sama.

Perintah-perintah yang biasanya menampilkan rilis yang tidak lengkap itu sengaja membosankan:

npx electron-builder --publish never
test -f dist/latest.yml
test -f dist/latest-mac.yml
find dist -name "*.blockmap" -print

Pengecekan-pengecekan itu tidak menggantikan tes instalasi yang ditandatangani. Mereka menangkap kesalahan operasional saat mengunggah biner tanpa metadata yang dibutuhkan oleh klien untuk menemukannya.

Strategi Rollout, Channel, dan Rollback

Sumber rilis harus berperilaku lebih seperti target pengembangan daripada folder download. Jaga internal, beta, dan latest channel terpisah, dengan setiap channel didukung oleh manifest dan set artefak yang ditandatangani masing-masing. Promosi harus memindahkan rilis yang telah diuji antara kebijakan, bukan menggantikan file sementara klien sedang mengunduhnya.

Pemisahan channel juga melindungi produksi dari build uji coba yang tidak sengaja. Pembarui harus mengetahui apakah klien termasuk dalam kelompok internal, audiens beta, atau populasi stabil sebelum mengevaluasi sumber.

Gunakan kelompok sebelum paparan luas

Bidang manifest kustom dapat mengekspresikan pengiriman yang ditangguhkan:

version: 4.8.0
path: Example-Setup-4.8.0.exe
sha512: signed-artifact-hash
rolloutPercentage: 10

Proses utama dapat menetapkan wadah stabil per-pengguna, kemudian membandingkan wadah tersebut dengan rolloutPercentage. Penetapan stabil sangat penting. Pengguna yang berpindah antara status yang layak dan tidak layak pada setiap periksa akan menerima perilaku yang tidak terduga dan membuat laporan dukungan sulit untuk diinterpretasikan.

Perluas kelompok hanya setelah rilis telah bertahan di jendela pengamatan. Jendela yang tepat harus mencerminkan pola penggunaan Anda, tetapi keputusan harus didasarkan pada tanda-tanda, bukan pada kalender sendiri. Ikuti hasil periksa update, penyelesaian download, kesehatan peluncuran, kegagalan, kecuali renderer, dan keberhasilan autentikasi.

Jangan bingung rollback dengan menghapus artefak. Klien yang ada mungkin telah menyimpan metadata, dan beberapa mungkin sudah menjalankan versi yang buruk. Rencana rollback memerlukan rilis yang ditandatangani sebelumnya, perubahan feed, dan perilaku klien yang dapat pulih.

Aturan operasional: Rollback harus dapat dieksekusi oleh insinyur yang bertugas tanpa membangun kembali aplikasi selama insiden.

Dalam prakteknya, buku petunjuk harus mempromosikan manifest rilis sebelumnya kembali ke channel yang terkena dampak, membatalkan marker staging, dan memastikan bahwa periksa baru berlalu ke versi yang aman. Jika masalah ada di renderer code daripada shell native, rollback layer web yang spesifik mungkin lebih cepat. Platform seperti code rollouts yang berfase Capgo adalah platform rollouts yang berfase Dapat relevan untuk layer pengiriman terpisah, tetapi tidak boleh mengaburkan batasan antara pengembalian biner asli dan pengembalian rollback bundle web.

Menangani Auto-Update sebagai Pengendalian Keamanan

Sebuah pembarui Electron mengunduh eksekutor code dan dapat menginstalnya dengan interaksi pengguna yang sedikit. Hal ini membuat jalur pembaruan menjadi batasan keamanan, bukan hanya fitur kenyamanan. Dokumentasi resmi Electron menjelaskan keterbatasan platform seperti ATS macOS, dan penutupan keamanan telah mendokumentasikan skenario 2022 di mana penyerang yang mengontrol infrastruktur pembaruan dapat menyajikan paket berbahaya yang masih lolos verifikasi code-penandatanganan, seperti yang dibahas dalam dokumentasi keamanan auto-update Electron Builder. Dokumentasi Keamanan Otomatis Update Pembangun Electron.

Code signing remains foundational, but it isn’t the whole trust model. Sign every release, verify the certificate and identity during CI, and maintain a documented key-rotation procedure. On macOS, combine signing with notarization and the hardened runtime appropriate to your application. On Windows, make certificate ownership, renewal, and build access auditable. Linux needs a distribution-specific strategy because Electron doesn’t provide a built-in universal updater there.

Menangani Auto-Update sebagai Pengendalian Keamanan

Jika metadata channel terkorupsi atau tidak terkonfigurasi dengan benar, maka file biner yang ditandatangani masih dapat terkait dengan rilis yang salah. Pertimbangkan untuk menambahkan tanda tangan manifesto yang diverifikasi terhadap kunci publik yang diintegrasikan dalam aplikasi, menetapkan versi minimum yang diizinkan, dan menolak penurunan versi yang tidak terduga kecuali ada jalur pemulihan yang telah disetujui secara eksplisit.

Feed juga memerlukan kontrol produksi:

• Restriksi akses publikasi: Berikan CI hanya hak akses yang diperlukan untuk menerbitkan aset rilis.
• Pelindungi rahasia tanda tangan: Tahan sertifikat dan kunci pribadi di penyimpanan rahasia yang dikelola, bukan file repository.
• Pegang dependensi: Lock Electron, electron-builder, dan dependensi transitif di CI.
• Ulas artefak: Scan paket yang dihasilkan dan bandingkan dengan komit yang dimaksud dan versi.
• Memerlukan transportasi yang aman: Ikuti ATS dan persyaratan HTTPS ketat untuk permintaan pembaruan.
• Pengecekan gagal verifikasi: Tangani ulang tanda tangan atau kegagalan manifesto sebagai kejadian keamanan, bukan sebagai kebisingan jaringan biasa.

Ecosystem tooling yang dipelihara oleh Electron terus menambahkan penutupan dan penutupan pembaruan, tetapi pemeliharaan tidak menghilangkan kebutuhan untuk model ancaman. Tujuan praktis adalah untuk memastikan bahwa penyerang yang mengompromikan wadah, CDN, atau langkah pembangunan masih tidak dapat membuat klien menerima rilis tidak berwenang. The Petunjuk Verifikasi Tanda Tangan memberikan konteks yang berguna untuk merancang lapisan verifikasi tambahan tersebut.

Produksi Update Runbook dan Checklist

Rilis siap hanya ketika insinyur lain dapat mengoperasikannya di bawah tekanan. Simpanlah checklist dekat dengan pekerjaan pengiriman dan saluran insiden.

Gates pra-rilis

• Identitas versi: Konfirmasikan versi paket, tag rilis, SHA komit, dan catatan perubahan setuju.
• Penandatanganan: Pastikan setiap artefak platform telah ditandatangani dan notarisasi atau validasi setara telah selesai.
• Kontrak Manifest: Konfirmasi latest.yml, latest-mac.yml, hash, jalur, dan blockmaps sesuai dengan artefak yang diunggah.
• Keamanan Channel: Publikasikan ke dalam pakan internal atau beta sebelum mempromosikan saluran rilis.
• Telemetri: Konfirmasi periksa update, kemajuan download, instalasi selesai, kesehatan peluncuran, dan kesalahan yang datang.

Canary dan peluncuran penuh

• Pengendalian kohort: Mulai dengan audiens internal atau beta yang sengaja kecil.
• Anggaran kesehatan: Jika gagal peluncuran, gagal download update, kecuali kecuali kegagalan renderer atau kegagalan autentikasi melebihi batasan yang disetujui tim, maka promosi dihentikan.
• Persetujuan promosi: Memerlukan keputusan eksplisit untuk maju atau mundur sebelum memindahkan rilis ke feed stabil.
• Dampak pelanggan: Siapkan pesan dukungan sebelum distribusi luas, bukan setelah insiden pertama.

Respons Insiden

Jika binary baru gagal diluncurkan, proses spawning gagal, atau download update berhenti selesai, maka promosi dihentikan segera. Kembalikan manifest yang ditandatangani sebelumnya, hapus marker staging, dan pastikan klien segar mengarah ke versi sebelumnya. Kemudian, konfirmasi melalui telemetri bahwa armada sedang pulih sebelum berkomunikasi tentang penutupan.

Perintah rollback yang tepat tergantung pada penyedia Anda, tetapi urutan harus selalu dokumentasi: Flip manifest channel ke versi sebelumnya, hapus tag staging, kirim marker update paksa jika perlu, dan pastikan jalur turun ke versi sebelumnya dengan telemetri hidup.Jika rollback belum diuji, maka hanya harapan.

Capgo menawarkan pembaruan Electron untuk mengirimkan perubahan layer web yang ditandatangani, saluran yang ditargetkan, kontrol peluncuran, dan observabilitas update tanpa membangun shell native untuk setiap perubahan renderer. Jika Anda ingin memisahkan rilis binary native dari pengiriman JavaScript dan CSS yang dikendalikan, kunjungi Capgo dan evaluasi bersama dengan pipeline rilis Electron Anda.