Mise en œuvre d'une mise à jour automatique d'applications Electron : Un guide pratique 2026

Vous avez déployé la build Electron, la page de lancement est en ligne, et le premier ticket de support arrive avant que la machine à café ne se termine. Un utilisateur dit que l'application n'a jamais trouvé la mise à jour. Un autre l'a téléchargée mais ne peut 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 heures du matin qui a déclenché ce guide
• Choisir le bon chemin de mise à jour d'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
  • Tenez le rendu informé sans bloquer le travail
• Brancher la CI/CD pour les sorties signées et les manifestes
  • Faites de 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 plan de vérification de mise à jour en production
  • Les portes de pré-sortie
  • Canary et déploiement complet
  • Réponse à l'incident

L'incident de mise à jour qui a déclenché ce guide : 2 h du matin

La mise en production a réussi 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'éléments pour rendre la mise à jour complète. L'application a démarré en test, mais personne n'avait exercé le chemin d'actualisation à partir d'une build de production installée.

À 2 h 08, PagerDuty a alerté l'ingénieur de garde. Une nouvelle flux d'authentification a échoué pour une partie de la flotte, et les utilisateurs qui ont reçu la mise à jour 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 à jour défectueuse, 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 à jour Le binaire existait, mais les métadonnées attendues n'établissaient pas 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'était pas 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 preuve fiable.
4. Vérifiez les contrôles de déploiement. Il n'y avait pas de canal interne ou de cohorte étalonnée. Tous les clients éligibles utilisaient le même flux, donc l'échec s'est propagé sans point de contenance.
5. Recherchez un roulage. 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 de la plateforme 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 un 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érationnel . La 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 est un chemin testé plutôt qu'une invention d'urgence.

Choisir le bon chemin de mise à jour d'Electron

À 2 heures du matin, la mauvaise choix de mise à jour devient un problème opérationnel. Une mise à jour de code binaire native doit gérer la signature, les manifestes, les installateurs et le retrait. Une mise à jour de code JavaScript ou CSS uniquement du rendu suit un chemin différent. Les contraintes d'hébergement comptent également : un petit projet hébergé par GitHub 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 mise en route. Il prend en charge plusieurs modèles de hébergement, mais votre équipe conserve la responsabilité de la signature, de la disponibilité de la source, de la politique de canal, des contrôles de déploiement et de la surveillance. L'intégration de l'actualiseur Electron pour Capgo est pertinente lors de l'évaluation d'un modèle de livraison hybride pour les lots de couches web aux côtés des versions natives.

update-electron-app suit les équipes qui veulent une petite intégration autour des GitHub Versions. Il vérifie au démarrage et ensuite à intervalles réguliers, ce qui garde la mise en place simple mais laisse moins de place pour une sélection avancée de canaux, un trafic étalé, et des règles de retrait personnalisées. Le package est raisonnable pour un processus de versionnement petit, à condition que les GitHub Versions et leur disponibilité correspondent aux exigences opérationnelles de votre équipe.

A un service personnalisé comme Hazel, Nuts ou un flux interne convient lorsque l'autorisation de mise en production, la ciblage de 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 releases rejetées et le comportement de reprise.

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 natives, 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 s'arrête.

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() se produit uniquement lors du démarrage est un erreur courante dans la production. Un utilisateur peut laisser l'application ouverte pendant des jours, donc le processus principal nécessite un intervalle contrôlé et 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, testez donc à partir d'artefacts installés plutôt que du mode de développement. La documentation d'Electron met également en garde contre les préoccupations de timing de démarrage sur Windows, y compris 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 dont elle a besoin.

Maintenez l'informé 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 volontairement 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.';
  }
});

Interrompez 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éfinissez 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 horaire, et non seulement au lancement. Ensuite, l'événement doit atteindre les journaux et la télémétrie. Si l'application avalise l'événement sans le signaler, votre error apparaîtra comme si elle ne fonctionnait pas. flux de dépannage d'application se déroule au hasard plutôt qu'en fonction de preuves.

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

La chaîne de livraison est la source de vérité pour ce que les utilisateurs installent. Un build local 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 sortie.

Le modèle de publication d'Electron-builder s'attend à ce que les métadonnées de sortie 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.

Rendre 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 devrait 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 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. Le guide de configuration de l'intégration continue est utile lors de la formalisation de ces vérifications, et les équipes comparant l'orchestration de pipeline peuvent également bénéficier de comprendre quand utiliser Jenkins et Ansible ensemble.

Les commandes qui exposent généralement une mise en production 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 cependant l'erreur opérationnelle consistant à télécharger un binaire sans les métadonnées nécessaires aux clients pour le découvrir.

Rollouts, stratégies de canal et stratégie de reprise

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 derniers canaux séparés, chacun étant soutenu par son propre manifeste et ensemble d'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 une livraison étalée :

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

Le processus principal peut affecter un bac stable par utilisateur, puis comparer ce bac avec rolloutPercentageLa mise en place 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.

Élargir le groupe uniquement 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.

Dans la 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 outil 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 paquets web. Capgo phased rollouts Un mises à jour Electron télécharge des exécutables __CAPGO_KEEP_0__ et peut les installer avec peu d'interaction de l'utilisateur. Cela fait de la voie d'update une

Une mise à jour peut être téléchargée et installée avec peu d'interaction de l'utilisateur. Cela fait de la voie d'update une

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 fonctionnalité de commodité. La documentation officielle d'Electron décrit les contraintes de la 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é approprié à 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é, pas dans des fichiers de dépôt.
• Fixez les dépendances : Verrouillez Electron, electron-builder et les dépendances transitives dans CI.
• Examinez les artefacts : Analysez les packages générés et comparez-les avec le commit et la version prévus.
• Exigez un transport sécurisé : Suivez les exigences ATS et HTTPS strictes pour les demandes d'actualisation.
• Surveillez 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 de Electron maintenu 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 si un attaquant compromet un conteneur, une CDN ou une étape de construction, il 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 la liste de vérification de production

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

Les portes de pré-mise à jour

• L'identité de la version : Confirmer la version du package, la balise de mise à jour, l'identifiant SHA de la commit et le changelog s'accordent.
• La signature : Vérifier que chaque artefact de plateforme est signé et que la non-attribution ou une validation équivalente a été effectuée.
• Le contrat de manifeste : Confirmer latest.yml, latest-mac.yml, les hachages, les chemins et les cartes de blocs correspondent aux artefacts téléchargés.
• La sécurité du canal : Publier sur le flux interne ou bêta avant de promouvoir le canal de mise à jour.
• Telemetry : Les vérifications d'actualisation, la progression 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 : Démarrer avec un petit auditoire interne ou bêta délibérément.
• Budget de santé : Retenir la promotion si les échecs de lancement, les échecs de téléchargement d'actualisation, les exceptions du rendu ou les échecs d'authentification dépassent les limites approuvées par l'équipe.
• Approbation de promotion : Exiger une décision explicite de continuer ou d'arrêter avant de déplacer la version vers le flux stable.
• Impact sur le client : Préparer le message de soutien avant la distribution large, et non après le premier incident.

Réponse à l'incident

If 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 vers 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 dégradation 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 reconstruire la coquille native pour chaque modification du rendu. Si vous souhaitez séparer les sorties binaires natives des livraisons de JavaScript et de CSS contrôlées, visitez Capgo et évaluez-l’en parallèl’avec votre pipeline de sortie existant d'Electron.