Electron App Auto Mise à Jour : Un Guide Pratique 2026

Vous avez déployé la build Electron, la page de mise à jour est en ligne, et le premier ticket de support arrive avant que la machine à café ait fini. Un utilisateur dit que l'application n'a jamais trouvé la mise à jour. Un autre l'a téléchargée mais ne peut pas l'installer. Un troisième continue à utiliser une ancienne version avec un flux d'authentification cassé, tandis que vos journaux montrent presque rien d'utile.

C'est la réalité inconfortable de Electron app mise à jour automatique. La mise à jour API est uniquement un composant. Une mise en production dépend également de la signature de la plateforme, de la politique de transport, des manifestes, de l'hébergement, des événements de cycle de vie, de l'observabilité, des contrôles de déploiement et d'un chemin de reversion. Traitez n'importe lequel de ceux-ci comme optionnel et une mise à jour de routine peut devenir un incident nocturne.

Table des matières

• La Mise à Jour de 2 H 00 du Matin Qui a Déclenché Cette Guide
• Choisir le Bon Chemin de Mise à Jour pour Electron
• Implémenter le Flux de Mise à Jour Automatique dans le Processus Principal
  • Configurez d'abord la cible de publication
  • Planifiez les vérifications et exposez les événements de cycle de vie
  • Tenir le rendu informé sans bloquer le travail
• Brancher la CI/CD pour les Mises en Production Signées et les Manifestes
  • Faites la signature explicite dans la CI
• Rollouts, Canaux et Stratégie de Reversion
  • Utilisez les cohortes avant une exposition large
• Traitez l'actualisation automatique comme un contrôle de sécurité
  • Protégez les métadonnées avec autant de soin que le binaire
• Le guide et le tableau de bord d'actualisation de production
  • Les portes de pré-lancement
  • Canary et déploiement complet
  • Réponse à l'incident

L'incident d'actualisation qui a déclenché ce guide à 2 heures du matin

La mise en production a passé les tests de CI et semblait ordinaire. Le vendredi soir, un développeur a poussé une build d'Electron non signée, et le job de publication a téléchargé suffisamment d'actifs pour rendre la mise en production complète. L'application a démarré en test, mais personne n'avait exercé la voie d'actualisation à partir d'une build de production installée.

À 2 h 08, PagerDuty a alerté l'ingénieur en charge. Une nouvelle flux d'authentification a échoué pour une partie de la flotte, et les utilisateurs qui ont reçu l'actualisation ne pouvaient pas terminer la connexion. Les autres utilisateurs sont restés sur la version précédente car l'actualiseur ne pouvait pas vérifier ou installer l'artifact. Certains clients avaient une mise en production brisée, tandis que le reste de la flotte exécutait une version différente sans explication claire.

L'enquête a suivi cinq vérifications :

1. Vérifiez la source de mise en production. Le binaire existait, mais les métadonnées attendues n'ont pas établi clairement lesquels clients devaient le recevoir. Un manifeste est un contrat entre la chaîne de livraison et les clients installés, et non un détail d'upload facultatif.
2. Inspectez la signature. La mise en ligne n'a pas été signée correctement, donc la vérification a échoué sur les plateformes affectées. La signature doit bloquer la publication lorsqu'elle est manquante ou invalide.
3. Comparez les journaux des clients. Les erreurs de mise à jour n'ont jamais atteint la télémétrie centrale. L'application a englouti l'événement et a continué à fonctionner, laissant l'équipe sans preuves fiables.
4. Vérifiez les contrôles de déploiement. Une chaîne interne ou un groupe de cohorte étape n'existait pas. Tous les clients éligibles utilisaient le même flux, donc l'échec s'est propagé sans point de contenance.
5. Recherchez une annulation. L'équipe n'avait pas de procédure testée pour républier la version précédente ou diriger les clients loin de la mise en ligne brisée.

La documentation officielle d'Electron fait les limites du plateau claires. Le Linux n'a pas de prise en charge intégrée de mise à jour automatique.et les demandes de mise à jour macOS doivent satisfaire Exigences de sécurité de transport d'applicationsLa documentation identifie également la signature comme prérequis pour des mises à jour macOS fiables et la vérification des versions de sortie. La Documentation de mise à jour automatique d'Electron Définit les contraintes API, tandis que le système de versionnage doit appliquer les contrôles opérationnels entourants.

Leçon post-mortem : Une mise à jour qui ne peut pas expliquer ce qui s'est passé est une tentative d'installation à distance avec des données de télémétrie manquantes.

Le coût s'est étendu au-delà du temps d'ingénierie. Les clients ont perdu confiance dans le client de bureau, le support a dû expliquer un comportement incohérent, et l'équipe a passé la prochaine journée de travail à reconstruire un processus de versionnage qui aurait dû exister avant l'incident.

Traitez la mise à jour automatique comme un Système opérationnelLa signature est une porte de sortie de version, les manifestes définissent le contrat du client, les canaux de déploiement limitent l'exposition, et le retrait reste un chemin testé plutôt qu'une invention d'urgence.

Choisir le bon chemin de mise à jour d'Electron

À 2 heures du matin, le mauvais choix de mise à jour devient un problème opérationnel. Une mise à jour de code natif doit gérer la signature, les manifestes, les installateurs et le retrait. Une modification de code JavaScript ou CSS uniquement en mode rendu suit un chemin différent. Les contraintes d'hébergement comptent également : un petit projet GitHub hébergé ne nécessite pas les mêmes contrôles de versionnage qu'un service de distribution d'entreprise.

For les projets utilisant electron-builder avec publication d'artefacts signés, electron-updater est généralement la solution pratique par défaut. Son écosystème couvre les cibles de publication, les manifestes de version, les téléchargements d'artefacts et l'installation à la prochaine lancement. Il prend en charge plusieurs modèles de hébergement, mais votre équipe possède toujours la gestion de la signature, la disponibilité de la source, la politique de canal, les contrôles de déploiement et la surveillance. Le Electron updater integration for Capgo Electron updater integration pour __CAPGO_KEEP_0__

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 un service personnalisé comme Hazel, Nuts ou un flux interne convient lorsque l'autorisation de publication, la ciblage du locataire, les enregistrements d'audit ou les règles de déploiement réglementé justifient le coût de mise en œuvre. L'équilibre est une propriété en cours. Votre équipe doit définir les sémiotiques du manifeste, protéger les clés de signature, préserver la compatibilité du client et tester les téléchargements échoués, les versions rejetées et le comportement de retrait.

Mises à jour en direct peuvent envoyer des modifications uniquement pour le rendu sans reconstruire la coquille native. Elles ne remplacent pas les mises à jour binaires lorsque Electron, les modules natifs, les autorisations ou le comportement de l'installateur changent. Utilisez electron-updater à moins que vous n'ayez besoin de logique de déploiement personnalisée. Si une logique personnalisée est requise, construisez autour des conventions de manifeste et d'artefact établies plutôt que de recréer le comportement de téléchargement et de mise à jour différentielle. Un chemin fiable est celui que votre équipe peut observer, étager et inverser sous pression.

Implémenter le flux d'Auto-Mise à jour dans le Processus Principal

Le processus principal doit gérer les vérifications de mise à jour et les installations. Le rendu peut afficher le statut, mais il ne doit pas décider si une mise à jour exécutable est fiable ou quand l'application quitte.

Configurez d'abord la cible de publication

Une configuration minimale d'electron-builder pourrait ressembler à ceci :

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

Conservez les flux bêta et stable séparés. Un canal est une politique de publication, et non une étiquette dans l'interface utilisateur. Chaque canal doit se résoudre à l'artefact signé et au manifeste correct.

Planifiez les vérifications et exposez les événements de cycle de vie

Appeler checkForUpdates() seulement pendant le démarrage est une erreur de production courante. Un utilisateur peut laisser l'application ouverte pendant des jours, donc le processus principal a besoin d'un intervalle contrôlé et d'une stratégie de réessai qui respecte l'opération hors ligne.

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;
  }
});

Le comportement exact de l'événement de mise à jour varie en fonction de la plateforme et de la configuration de packaging, il est donc préférable de tester à partir d'artefacts installés plutôt qu'en mode de développement. La documentation d'Electron met également en garde contre les préoccupations de timing de démarrage sur Windows, notamment le cas Squirrel first-run. N'activez pas une vérification de mise à jour avant que l'application n'ait terminé l'initialisation spécifique à la plateforme qu'elle nécessite.

Informer le rendu sans bloquer le travail

La passerelle de préchargement doit exposer un API étroit:

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

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

Une barre de progression côté rendu peut rester délibérément simple:

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

Garder l'installation derrière le consentement de l'utilisateur en production à moins que votre application n'ait une raison forte de redémarrer immédiatement. Définir un isQuitting flag avant quitAndInstall(), car les gestionnaires de fermeture de fenêtre normaux peuvent autrement empêcher l'installateur de prendre le contrôle.

Deux échecs méritent des tests explicites. Tout d'abord, un client déjà en cours d'exécution doit appeler checkForUpdates() sur un planning, et non seulement au lancement. Deuxièmement, l' error événement doit atteindre les journaux et la télémétrie. Si l'application avalise l'événement sans le signaler, votre flux de dépannage d'application commence par des suppositions au lieu de preuves.

Configuration de CI/CD pour les sorties signées et les manifestes

La chaîne de livraison de la version est la source de vérité pour ce que les utilisateurs installent. Une construction locale qui fonctionne sur une machine d'un développeur ne prouve pas que le binaire publié, le manifeste, la signature et le canal décrivent tous la même version.

Le modèle de publication d'Electron-builder s'attend à ce que les métadonnées de version et la cible de mise à jour voyagent ensemble. Pour beaucoup de configurations, cela signifie un artefact tel que latest.yml pour Windows et latest-mac.yml pour macOS, aux côtés de packages et de fichiers de blockmap spécifiques à la plateforme. Un manque de manifeste peut rendre un binaire parfaitement valide invisible aux clients.

Faites de la signature explicite dans CI

A simplified GitHub Actions pattern looks like this:

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

Utilisez des secrets spécifiques à la plateforme et gardez le matériau de signature à l'extérieur du dépôt. Un échec de signature devrait arrêter le job, et non produire un fallback non signé que quelqu'un télécharge manuellement.

La configuration de publication doit identifier le fournisseur et le canal de manière cohérente :

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

Avant la publication, filtrer le job en fonction de la version du package, de la balise, de l'ID de commit SHA et du résultat de test de fumée. Après la publication, vérifier que le flux contient le manifeste attendu et que le manifeste pointe vers l'artefact exact généré par ce job. guide de configuration de l'intégration continue est utile lorsque vous formalisez ces vérifications, et les équipes comparant l'orchestration de pipeline peuvent également bénéficier de comprendre lorsqu'il faut utiliser Jenkins et Ansible ensemble.

Les commandes qui exposent généralement une mise à jour incomplète sont intentionnellement ennuyeuses :

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

Ces vérifications ne remplacent pas un test d'installation signé. Elles capturent l'erreur opérationnelle consistant à télécharger un binaire sans les métadonnées dont les clients ont besoin pour le découvrir.

Rollouts, canaux et stratégie de retrait

Un flux de version devrait se comporter plus comme une cible de déploiement qu'un dossier de téléchargement. Gardez intérieur, bêta, et les dernières les canaux séparés, chacun étant soutenu par son propre manifeste et ensemble de artefacts signés. La promotion devrait déplacer une version testée entre les politiques, et non écraser un fichier pendant que les clients le téléchargent.

La séparation des canaux protège également la production contre les builds de test accidentels. L'actualiseur devrait savoir si un client appartient à un groupe de test interne, à un public bêta ou à la population stable avant d'évaluer le flux.

Utilisez les groupes avant une exposition large

Un champ de manifeste personnalisé peut exprimer la livraison étalée :

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

Le processus principal peut attribuer un bac stable par utilisateur, puis comparer ce bac avec rolloutPercentageL'attribution stable compte. Un utilisateur qui passe entre les états éligibles et non éligibles à chaque vérification recevra un comportement imprévisible et rendra les rapports de support difficiles à interpréter.

Étendez uniquement le groupe après que la mise à jour ait survécu à sa fenêtre d'observation. La fenêtre exacte devrait refléter votre modèle d'utilisation, mais la décision devrait être basée sur des signaux, et non sur un calendrier seul. Suivez les résultats de la vérification des mises à jour, la fin de la téléchargement, la santé de lancement, les plantages, les exceptions du rendu et le succès de l'authentification.

N'établissez pas de confusion entre le retrait et la suppression d'un artefact. Les clients existants peuvent avoir des métadonnées mises en cache, et certains peuvent déjà exécuter la mauvaise version. Un plan de retrait nécessite une version signée précédente, une modification de la source, et un comportement du client qui peut se rétablir.

Règle opérationnelle : Le retrait doit être exécutable par l'ingénieur de permanence sans reconstruire l'application pendant l'incident.

En pratique, le livre de procédures devrait promouvoir le manifeste de la version précédente vers le canal affecté, invalider le marqueur de mise en scène, et confirmer que les nouvelles vérifications se résolvent vers la version sûre. Si l'incident se produit dans le rendu code plutôt que dans la coquille native, un retrait ciblé du niveau web peut être plus rapide. Un tel système de mise en production phasée peut être pertinent pour ce niveau de livraison séparé, mais il ne doit pas obscurcir la frontière entre un retrait de binaires natifs et un retrait de bundles web. Capgo phased rollouts Un mises à jour Electron télécharge des __CAPGO_KEEP_0__ exécutables et peut les installer avec peu d'interaction utilisateur. Cela fait de la voie d'update une

route de mise à jour

An Electron updater downloads executable code and can install it with little user interaction. That makes the update path a la frontière de sécurité, ce n'est pas simplement un avantage. La documentation officielle d'Electron décrit les contraintes de plateforme telles que macOS ATS, et la couverture de sécurité a documenté un scénario de 2022 dans lequel les attaquants contrôlant l'infrastructure de mise à jour pouvaient servir des packages malveillants qui passaient encore les vérifications de signature code la documentation de sécurité d'auto-mise à jour d'Electron Builder.

les vérifications de signature Code restent fondamentales, mais ce n'est pas le modèle de confiance entier. Signez chaque version, vérifiez le certificat et l'identité pendant la CI, et maintenez une procédure de rotation de clés documentée. Sur macOS, combinez la signature avec la notarisation et le runtime durcisés appropriés à votre application. Sur Windows, faites de la propriété, de la renouvellement et de l'accès à la construction des certificats auditable. Linux nécessite une stratégie spécifique à la distribution car Electron ne fournit pas un mises à jour universel intégré là-bas.

Protégez les métadonnées avec autant de soin que le binaire

Un binaire signé peut toujours être associé à la mauvaise version si le canal de métadonnées est compromis ou mal configuré. Considérez l'ajout d'une signature de manifeste vérifiée contre une clé publique intégrée à l'application, imposez une version minimale autorisée, et rejetez les descentes inattendues à moins qu'un chemin de récupération autorisé ne les permet explicitement.

La source de données mérite également des contrôles de production :

• Restreignez l'accès à la publication : Accordez à la CI uniquement les permissions requises pour publier les actifs de version.
• Protégez les secrets de signature : Conservez les certificats et les clés privées dans un stockage de secrets géré, et non dans des fichiers de dépôt.
• Dépendances à fixer : Verrouillez Electron, electron-builder et les dépendances transitives dans CI.
• Examiner les artefacts : Analysez les packages générés et comparez-les avec le commit et la version prévus.
• Exiger un transport sécurisé : Suivez les exigences ATS et HTTPS strictes pour les demandes d'actualisation.
• Surveiller les échecs de vérification : Traitez les échecs de signature ou de manifeste répétés comme des événements de sécurité, et non comme du bruit de réseau ordinaire.

Le système d'outils maintenu par Electron continue d'ajouter une couverture de packaging et d'actualisation, mais la maintenance n'enlève pas la nécessité de modéliser les menaces. L'objectif pratique est d'assurer que l'attaquant qui compromet un conteneur, un CDN ou une étape de construction ne peut toujours pas faire accepter au client une mise à jour non autorisée. La guidance de vérification de signature fournit un contexte utile pour concevoir cette couche de vérification supplémentaire.

Le guide de mise à jour et le plan de vérification de production

Une mise à jour est prête uniquement lorsque les autres ingénieurs peuvent l'exploiter sous pression. Gardez le plan de vérification proche de l'opération de déploiement et du canal d'incident.

Les portes de pré-mise à jour

• Identité de version : Confirmer la version du package, la balise de mise à jour, l'identifiant de commit SHA et le changelog s'accordent.
• Signature : Vérifier que chaque artefact de plateforme est signé et que la notarisation ou une validation équivalente a été effectuée.
• Contrat de manifeste : Confirmer latest.yml, latest-mac.ymlLes hashes, les chemins et les blockmaps correspondent aux artefacts téléchargés.
• Sécurité du canal : Publier sur le flux interne ou de bêta avant de promouvoir le canal de mise à jour.
• Telemetry : Les mises à jour de confirmation, les progrès de téléchargement, la fin de l'installation, la santé de lancement et les erreurs arrivent.

Canary et déploiement complet

• Contrôle de cohorte : Commencez avec un public interne ou bêta délibérément petit.
• Budget de santé : Retenez la promotion si les échecs de lancement, les échecs de téléchargement de mise à jour, les exceptions de rendu ou les échecs d'authentification dépassent les limites approuvées par l'équipe.
• Approbation de la promotion : Exigez une décision explicite aller ou ne pas aller avant de déplacer la version vers le flux stable.
• Impact sur le client : Préparez les messages de support avant la distribution large, et non après le premier incident.

Réponse à l'incident

Si le nouveau binaire ne démarre pas, la création de processus est interrompue ou les téléchargements d'actualisation s'arrêtent de se terminer, arrêtez immédiatement la promotion. Rétablissez le manifeste signé précédent, invalidez le marqueur de mise en scène, et vérifiez que les clients frais se résolvent à la version précédente. Confirmez ensuite par télémétrie que la flotte se rétablit avant de communiquer la fermeture.

La séquence exacte des commandes de reversion dépend de votre fournisseur, mais la séquence devrait toujours être documentée : Flanchez le manifeste de canal vers la version précédente, invalidez le tag de mise en scène, poussez un marqueur d'actualisation forcée si la récupération le nécessite, et vérifiez le chemin de reversion avec la télémétrie en direct.Une reversion qui n'a pas été testée n'est qu'une espérance.

Capgo propose un actualiseur Electron pour livrer des modifications de couches web signées, des canaux ciblés, des contrôles de lancement et l'observabilité des mises à jour sans recompiler la coquille native pour chaque changement de rendu. Capgo __CAPGO_KEEP_0__