Aplikasi Otomatis Update Electron: Panduan Praktis 2026

Anda telah mengirimkan bangunan Electron, halaman rilis sudah aktif, dan tiket dukungan pertama datang sebelum mesin kopi selesai. Salah satu pengguna mengatakan aplikasi tidak menemukan pembaruan. Yang lain mengunduhnya tetapi tidak bisa menginstalnya. Yang ketiga masih menjalankan versi lama dengan alur autentikasi yang rusak, sementara log Anda menunjukkan tidak ada informasi yang berguna.

Kenyataan yang tidak nyaman itu Update Otomatis Aplikasi Electron. Pengatur API hanya satu komponen. Rilis produksi juga bergantung pada tanda tangan platform, kebijakan transportasi, manifest, hosting, kejadian siklus, observabilitas, kontrol peluncuran, dan jalur rollback. Anggap salah satu dari itu sebagai opsional dan patch rutin dapat menjadi insiden malam hari.

Daftar Isi

• Kasus Update Malam 2 yang Membuat Panduan Ini
• Pilih Jalur Pengatur Update Electron yang Tepat
• Mengimplementasikan Aliran Update Otomatis di Proses Utama
  • Konfigurasi target publikasi terlebih dahulu
  • Jadwalkan periksa dan terbuka kejadian siklus
  • Tetapkan renderer terinformasi tanpa menghalangi pekerjaan
• Menghubungkan CI/CD untuk Rilis Tanda Tangan dan Manifest
  • Jadikan tanda tangan eksplisit di CI
• Strategi Peluncuran, Saluran, dan Jalur Rollback
  • Gunakan kelompok sebelum paparan luas
• Tangani Auto-Update sebagai Kontrol Keamanan
  • Lindungi metadata dengan hati-hati seperti biner
• Kit Buku dan Daftar Periksa Pembaruan Produksi
  • Gardu Pra-rilis
  • Rollout Canary dan Penuh
  • Tanggapi Insiden

Insiden Pembaruan Pukul 2 yang Membuat Ini Panduan

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

Pukul 2:08 dini hari, PagerDuty mengingatkan insinyur yang bertugas. Aliran autentikasi baru gagal untuk sebagian armada, dan pengguna yang menerima pembaruan tidak dapat menyelesaikan 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.

Penginvestigasian mengikuti lima pemeriksaan:

1. Pemeriksaan Feed Rilis Binary tersebut ada, tapi metadata yang diharapkan tidak jelas menetapkan mana klien yang harus menerima itu. Manifest adalah kontrak antara pipa rilis dan klien yang terpasang, bukan detail unggah yang opsional.
2. Periksa tanda tangan. Rilis tersebut tidak ditandatangani dengan benar, sehingga verifikasi gagal pada platform yang terkena dampak. Tanda tangan harus menghalangi publikasi ketika itu hilang atau tidak valid.
3. Bandingkan log klien. Error pembaruan tidak pernah mencapai telemetri pusat. Aplikasi menelan event tersebut dan terus berjalan, meninggalkan tim tanpa bukti yang dapat diandalkan.
4. Periksa pengendalian rollout. Tidak ada saluran internal atau kohort yang dipersiapkan. Setiap klien yang layak menggunakan sumber yang sama, sehingga gagalnya menyebar tanpa titik pengendalian.
5. Cari rollback. Tim tidak memiliki prosedur yang telah diuji untuk mempublikasikan versi sebelumnya atau mengarahkan klien menjauhi rilis yang rusak.

Dokumentasi resmi Electron menjelaskan batasan platform secara jelas. Linux tidak memiliki dukungan auto-updater bawaan., dan permintaan pembaruan macOS harus memenuhi Persyaratan Keamanan Transport Aplikasi Dokumentasi juga mengidentifikasi tanda tangan sebagai prasyarat untuk pembaruan macOS yang dapat diandalkan dan verifikasi rilis. Dokumentasi autoUpdater Electron Menggambarkan keterbatasan API , sementara sistem rilis harus mengimplementasikan kontrol operasional yang melingkari.

Pelajaran Pasca-Kematian: Sebuah pembaruan yang tidak dapat menjelaskan apa yang terjadi adalah upaya instalasi jarak jauh dengan telemetri yang hilang.

Biaya meluas di luar waktu rekayasa. Pelanggan kehilangan kepercayaan pada klien desktop, dukungan harus menjelaskan perilaku yang tidak konsisten, dan tim menghabiskan hari kerja berikutnya untuk membangun kembali proses rilis yang seharusnya ada sebelum insiden.

Tentukan Jalur Pembaruan Electron yang Tepat Pada pukul 2 pagi, pilihan pembaruan yang salah menjadi masalah operasional. Pembaruan biner asli harus menangani tanda tangan, manifest, installer, dan rollback. Perubahan JavaScript atau CSS hanya renderer tidak mengikuti jalur yang sama. Keterbatasan hosting juga berperan: proyek kecil __CAPGO_KEEP_0__-hosted tidak memerlukan kontrol rilis yang sama seperti layanan distribusi perusahaan.Pemilihan Jalur Pembaruan Electron yang Tepat

Di 2 pagi, pilihan pembaruan yang salah menjadi masalah operasional. Pembaruan biner asli harus menangani tanda tangan, manifest, installer, dan rollback. Perubahan JavaScript atau CSS hanya renderer tidak mengikuti jalur yang sama. Keterbatasan hosting juga berperan: proyek kecil __CAPGO_KEEP_0__-hosted tidak memerlukan kontrol rilis yang sama seperti layanan distribusi perusahaan.

At 2 a.m., the wrong updater choice becomes an operational problem. A native binary update must handle signing, manifests, installers, and rollback. A renderer-only JavaScript or CSS change follows a different path. Hosting constraints also matter: a small GitHub-hosted project does not need the same release controls as an enterprise distribution service.

Untuk proyek yang menggunakan electron-builder dengan publikasi artifact yang ditandatangani, electron-updater biasanya adalah 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 memiliki tanggung jawab atas tanda tangan, ketersediaan feed, kebijakan saluran, kontrol peluncuran, dan pemantauan. Electron updater integration for Capgo relevant ketika mengevaluasi model pengiriman hybrid 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.

A layanan khusus seperti Hazel, Nuts, atau sumber internal cocok ketika otorisasi rilis, target penyewa, catatan audit, atau aturan pengiriman yang diatur membenarkan biaya implementasi. Kompromi yang berlangsung adalah kepemilikan yang berkelanjutan. Tim Anda harus menentukan semantik manifesto, melindungi kunci tanda tangan, mempertahankan kompatibilitas klien, dan menguji download gagal, rilis yang ditolak, dan perilaku rollback.

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

Mengimplementasikan Alur Auto-Update di Proses Utama

Proses utama harus menguasai periksa pembaruan dan instalasi. Renderer dapat menampilkan status, tetapi tidak boleh menentukan apakah pembaruan eksekutif dapat dipercaya atau ketika aplikasi keluar.

Konfigurasi target publik terlebih dahulu

Konfigurasi electron-builder yang minimal mungkin terlihat seperti ini:

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

Pertahankan sumber beta dan stabil terpisah. Saluran adalah kebijakan rilis, bukan label di UI. Setiap saluran harus menyelesaikan ke artifact yang ditandatangani dan manifesto yang benar.

Jadwalkan periksa dan terbuka event kehidupan

Panggil checkForUpdates() kesalahan produksi umum selama startup. Pengguna dapat meninggalkan aplikasi terbuka selama hari-hari, sehingga proses utama membutuhkan interval yang dikontrol 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 event yang tepat berbeda-beda tergantung pada platform dan pengaturan pengemasan, sehingga tes dari artefak yang diinstal daripada mode pengembangan. Dokumentasi Electron juga menyebutkan kekhawatiran waktu startup pada Windows, termasuk kasus Squirrel pertama kali. Jangan memicu periksa update sebelum aplikasi telah menyelesaikan inisialisasi spesifik platform yang dibutuhkan.

Tetapkan informasi renderer tanpa menghalangi pekerjaan

Pintu jembatan preload harus menampilkan API yang sempit:

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

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

Gelombang progress 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.';
  }
});

Jalankan instalasi di belakang persetujuan pengguna di produksi kecuali aplikasi Anda memiliki alasan kuat untuk restart segera. Atur flag sebelum isQuitting karena handler tutup jendela normal dapat mencegah installer dari mengambil alih. quitAndInstall()Screenshot dari https://raw.githubusercontent.com/electron-userland/electron-builder/master/docs/electron-builder-autoupdate.png

pada jadwal, bukan hanya pada peluncuran. Kedua, event checkForUpdates() harus mencapai log dan telemetri. Jika aplikasi menelaninya tanpa melaporkan, maka error update Anda tidak akan berfungsi dengan baik. Alur kerja troubleshooting aplikasi dimulai dengan spekulasi bukan bukti.

Menghubungkan CI/CD untuk Rilis Tanda Tangan dan Manifest

Alur rilis adalah sumber kebenaran untuk apa yang diinstal oleh pengguna. Pembangunan lokal yang berhasil di satu mesin pengembang tidak membuktikan bahwa file biner, 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, di samping paket khusus platform dan file blockmap. Manifest yang hilang dapat membuat file biner yang valid tidak terlihat oleh klien.

Jadikan tanda tangan eksplisit di CI

Gaya pola GitHub Actions yang disederhanakan 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

Pakai rahasia khusus 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 publikasi harus mengidentifikasi penyedia dan saluran secara konsisten:

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

Sebelum publikasi, jalankan pekerjaan pada versi paket, tag, SHA komit, dan hasil uji asap. Setelah publikasi, pastikan bahwa pakan berisi manifest yang diharapkan dan bahwa manifest mengarah ke artefak yang tepat yang dihasilkan oleh pekerjaan tersebut. Petunjuk pengaturan integrasi terus menerus bermanfaat ketika Anda formalisasi periksa, dan tim yang membandingkan orkestrasi pipa mungkin juga mendapat manfaat dari memahami ketika menggunakan Jenkins dan Ansible bersama-sama.

Perintah-perintah yang umumnya mengungkapkan rilis yang tidak lengkap adalah sengaja membosankan:

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

Periksa tidak menggantikan tes instalasi yang ditandatangani. Mereka menangkap kesalahan operasional mengunggah biner tanpa metadata yang dibutuhkan oleh klien untuk menemukannya.

Rilis, Saluran, dan Strategi Rollback

Apa itu sumber penerbitan harus berperilaku lebih seperti target pengiriman daripada folder download. Simpan internal, beta, dan latest saluran terpisah, dengan setiap saluran didukung oleh manifest dan set artefak yang ditandatangani sendiri. Promosi harus memindahkan rilis yang telah diuji antara kebijakan, bukan menggantikan file sementara klien sedang mengunduhnya.

Saluran terpisah juga melindungi produksi dari bangunan uji yang tidak sengaja. Pembarui harus mengetahui apakah klien termasuk dalam kelompok internal, audiens beta, atau populasi stabil sebelum mengevaluasi sumber.

Pakai kelompok sebelum pemaparan luas

Field manifest kustom dapat mengekspresikan pengiriman yang dipersiapkan:

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

Proses utama dapat menetapkan wadah per-pengguna yang stabil, kemudian membandingkannya dengan rolloutPercentage. Penetapan stabil 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 kohort hanya setelah rilis telah bertahan di jendela pengamatan. Jendela yang tepat harus mencerminkan pola penggunaan Anda, tetapi keputusan harus berdasarkan signal, bukan hanya kalender. Pantau hasil periksa update, penyelesaian download, kesehatan peluncuran, crash, kecuali renderer, dan keberhasilan autentikasi.

Tidak bingungkan rollback dengan menghapus artefak. Klien yang sudah ada mungkin memiliki metadata yang dicache, 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 run harus mempromosikan manifest rilis sebelumnya ke saluran 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 dapat relevan untuk lapisan pengiriman yang terpisah, tetapi tidak boleh mengaburkan batasan antara rollback biner native dan rollback bundle web. Capgo phased rollouts Updater Electron mengunduh eksekusi __CAPGO_KEEP_0__ dan dapat menginstalnya dengan interaksi pengguna yang sedikit. Hal itu membuat jalur update menjadi

Signal tetap berada dalam anggaran rilis

An Electron updater downloads executable code and can install it with little user interaction. That makes the update path a 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 code-pengecekan tanda tangan, seperti yang dibahas dalam Dokumentasi keamanan pembaruan Electron Builder.

tanda tangan Code tetap menjadi fondasi, tetapi bukan model kepercayaan yang utuh. Tanda tangan setiap rilis, verifikasi sertifikat dan identitas selama CI, dan jaga prosedur rotasi kunci yang terdokumentasi. Pada macOS, kombinasikan tanda tangan dengan notarisasi dan runtime yang diperkuat sesuai dengan aplikasi Anda. Pada Windows, buat kepemilikan sertifikat, perpanjangan, dan akses pembangunan yang dapat diaudit. Linux memerlukan strategi yang spesifik distribusi karena Electron tidak menyediakan pembaruan universal yang dapat digunakan di sana.

Jaga metadata dengan hati-hati seperti binary

Binary yang ditandatangani masih dapat terkait dengan rilis yang salah jika kanal metadata terkorupsi atau tidak terkonfigurasi dengan benar. Pertimbangkan menambahkan tanda tangan manifest yang diverifikasi terhadap kunci publik yang diintegrasikan dalam aplikasi, enforse versi yang diizinkan minimal, dan tolak penurunan yang tidak terduga kecuali jalur pemulihan yang diotorisasi secara eksplisit memungkinkannya.

Feed juga memerlukan kontrol produksi:

• Restriksi akses publik: Berikan CI hanya hak akses yang diperlukan untuk mempublikasikan aset rilis.
• Jaga rahasia tanda tangan: Simpan sertifikat dan kunci pribadi di penyimpanan rahasia yang dikelola, bukan file repository.
• Ketergantungan Pin: Simpan Electron, electron-builder, dan dependensi transitif di CI.
• Tinjau artefak: Skani paket yang dihasilkan dan bandingkan dengan komit yang diinginkan dan versi.
• Memerlukan transportasi aman: Ikuti ATS dan persyaratan HTTPS ketat untuk permintaan pembaruan.
• Pantau gagal verifikasi: Tangani ulang tanda tangan atau kegagalan manifest sebagai kejadian keamanan, bukan kebisingan jaringan biasa.

Sistem ekosistem alat yang dipelihara Electron terus menambahkan penutupan dan penutupan pembaruan, tetapi pemeliharaan tidak menghilangkan kebutuhan untuk model ancaman. Tujuan praktis adalah memastikan bahwa penyerang yang mengompromikan wadah, CDN, atau langkah pembangunan masih tidak dapat membuat klien menerima rilis yang tidak diotorisasi. Panduan tanda tangan yang disediakan memberikan konteks yang berguna untuk merancang lapisan verifikasi tambahan. Diagram proses pembaruan produksi empat langkah menampilkan verifikasi, peluncuran berjenjang, pemantauan insiden, dan protokol rollback.

Kit Buku dan Daftar Periksa Pembaruan Produksi

Rilis siap hanya ketika seorang insinyur lain dapat mengoperasikannya di bawah tekanan. Simpan daftar periksa dekat dengan pekerjaan pengembangan dan saluran insiden.

Gates Pra-Rilis

• Identitas Versi: Konfirmasikan versi paket, tag rilis, SHA komit, dan catatan perubahan setuju.
• Penandatanganan: Verifikasi setiap artefak platform ditandatangani dan notarisasi atau validasi setara telah selesai.
• Kontrak Manifest: Konfirmasikan latest.yml, latest-mac.yml, hash, jalur, dan blockmaps sesuai dengan artefak yang diunggah.
• Keamanan Saluran: 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: Tahan promosi jika gagal peluncuran, gagal download update, kecuali kejadian renderer, atau gagal autentikasi melebihi batasan yang disetujui tim.
• Persetujuan promosi: Memerlukan keputusan eksplisit untuk maju atau tidak sebelum memindahkan rilis ke pakan stabil.
• Dampak pelanggan: Siapkan pesan dukungan sebelum distribusi luas, bukan setelah insiden pertama.

Pengembalian insiden

Jika biner baru gagal diluncurkan, proses spawning gagal, atau download update berhenti selesai, hentikan promosi segera. Kembalikan manifest yang ditandatangani sebelumnya, buat marker staging tidak berlaku, dan pastikan klien segar mengarah ke versi sebelumnya. Kemudian, konfirmasikan melalui telemetri bahwa armada sedang pulih sebelum menyampaikan penutupan.

Perintah rollback yang tepat bergantung pada penyedia Anda, tetapi urutan harus selalu terdokumentasi: balikkan manifest saluran ke versi sebelumnya, buat tag staging tidak berlaku, kirim marker update paksa jika pemulihan memerlukan, dan pastikan jalur turun dengan telemetri hidup. Sebuah rollback yang belum diuji hanya harapan.

Capgo menawarkan pembaruan Electron untuk menyampaikan perubahan layer web yang ditandatangani, saluran yang ditargetkan, pengendalian peluncuran, dan observabilitas update tanpa membangun shell native untuk setiap perubahan renderer. Jika Anda ingin memisahkan rilis biner native dari pengiriman JavaScript dan CSS yang dikendalikan, kunjungi Capgo dan evaluasikan bersama dengan pipa rilis Electron yang ada Anda.