Elektron-App-Auto-Update: Eine praktische Anleitung 2026

Sie haben den Elektron-Build abgeschickt, die Release-Seite ist live und die erste Support-Anfrage kommt, bevor der Kaffeemaschine fertig ist. Ein Benutzer sagt, dass die App das Update nie gefunden hat. Ein anderer hat es heruntergeladen, aber kann es nicht installieren. Ein Dritter läuft noch immer einen alten Binary mit einem gebrochenen Authentifizierungsfluss, während Ihre Protokolle fast nichts Nützliches zeigen.

Das ist die unangenehme Realität von Elektron-App-Automatischer Update. Das Updater API ist nur ein Komponente. Eine Produktionsversion hängt auch von der Plattformsignatur, der Transportpolitik, den Manifesten, der Hosting, den Lebenszyklusereignissen, der Beobachtbarkeit, den Rollout-Controllen und einem Rücksetzpfad ab. Behandeln Sie jede dieser Optionen als verfügbar und ein Routine-Patch kann zu einer Nacht-Alarm-Situation werden.

Inhaltsverzeichnis

• Die 2-Uhr-Update-Incident, das diese Anleitung ausgelöst hat
• Die Wahl des richtigen Elektron-Update-Wegs
• Implementierung des automatischen Update-Flusses im Hauptprozess
  • Konfigurieren Sie das Veröffentlichungsziel zuerst
  • Planen Sie Überprüfungen und offenbaren Sie Lebenszyklusereignisse
  • Halten Sie den Renderer informiert, ohne die Arbeit zu blockieren
• Verbinden Sie CI/CD für signierte Versionen und Manifeste
  • Stellen Sie das Signieren explizit in CI ein
• Rollouts, Kanäle und Rollback-Strategie
  • Verwenden Sie Cohorten vor breiter Veröffentlichung
• Auto-Update als Sicherheitskontrolle behandeln
  • Die Metadaten so sorgfältig schützen wie das Binärdatei
• Das Produktionsupdate-Handbuch und -Checkliste
  • Prärelease-Schranken
  • Canary- und Vollausrollung
  • Reaktionsplan bei Vorfällen

Der 2-Uhr-Update-Vorfall, der diese Anleitung ausgelöst hat

Die Veröffentlichung hatte CI erfolgreich bestanden und sah normal aus. Am späten Freitag hatte ein Entwickler einen nicht signierten Electron-Build gepusht, und die Veröffentlichungsaufgabe hatte genügend Assets hochgeladen, um die Veröffentlichung vollständig erscheinen zu lassen. Die Anwendung startete in der Testumgebung, aber niemand hatte den Updatepfad von einer installierten Produktionsversion ausgetestet.

Um 2:08 Uhr meldete PagerDuty den aufgerufenen Ingenieur. Ein neuer Authentifizierungsfluss war für einen Teil der Flotte gescheitert, und Benutzer, die das Update erhalten hatten, konnten die Anmeldung nicht abschließen. Andere Benutzer blieben auf der vorherigen Version, weil der Updater die Artefakte nicht überprüfen oder installieren konnte. Einige Kunden hatten eine defekte Veröffentlichung, während der Rest der Flotte eine andere Version mit keiner klaren Erklärung lief.

Die Untersuchung folgte fünf Kontrollen:

1. Überprüfen Sie die Veröffentlichungsquelle. Die Binärdatei existierte, aber die erwartete Metadaten ließen nicht klar erkennen, welche Clients sie erhalten sollten. Ein Manifest ist ein Vertrag zwischen der Releasepipeline und den installierten Clients, nicht eine optionalen Upload-Detail.
2. Überprüfen Sie die Signierung. Die Release wurde nicht korrekt signiert, daher fehlte die Verifizierung auf betroffenen Plattformen. Die Signierung muss die Veröffentlichung blockieren, wenn sie fehlt oder ungültig ist.
3. Vergleichen Sie die Client-Protokolle. Update-Fehler erreichten nie die zentrale Telemetrie. Die Anwendung verschluckte das Ereignis und lief weiter, sodass das Team keine zuverlässige Beweise hatte.
4. Überprüfen Sie die Rollout-Kontrollen. Es gab keine internen Kanäle oder geschalteten Kohorten. Alle berechtigten Clients verwendeten denselben Feed, sodass das Versagen ohne ein Enthaftungspunkt ausbreitete.
5. Suchen Sie nach einer Rückschaltung. Das Team hatte keine getestete Verfahren, um die vorherige Version neu zu veröffentlichen oder die Clients von der defekten Release abzuwenden.

Die offizielle Dokumentation von Electron macht die Plattformgrenzen klar. Linux hat keine integrierte Unterstützung für Auto-Updatesund macOS-Update-Anfragen müssen die Anforderungen erfüllen App-Transport-SicherheitsanforderungenDie Dokumentation identifiziert auch die Signierung als Voraussetzung für zuverlässige macOS-Updates und -Freigaben. Die Elektron-Update-Dokumentation definiert die API-Beschränkungen, während das Release-System die umgebenden Betriebskontrollen durchsetzen muss.

Postmortem-Lektion: Ein Updater, der nicht erklären kann, was passiert ist, ist ein Remote-Installation-Versuch mit fehlender Telemetrie.

Der Aufwand reichte über die Zeit hinaus, die für die Inbetriebnahme erforderlich war. Kunden verloren das Vertrauen in den Desktop-Client, der Support musste unkonstantes Verhalten erklären, und das Team verbrachte den nächsten Arbeitstag damit, einen Release-Prozess wiederherzustellen, der vor dem Vorfall hätte existieren müssen.

Treat auto-update als Betriebssystem. Die Signierung ist ein Release-Gateway, Manifeste definieren den Client-Vertrag, Rollout-Kanäle begrenzen die Auswirkungen und Rollback bleibt ein getesteter Weg anstatt eine Notlösung.

Die Wahl des richtigen Electron-Update-Wegs

Bei 2 Uhr morgens wird die falsche Updater-Wahl zu einem Betriebssystemproblem. Ein natives Binärupdate muss Signierung, Manifeste, Installatoren und Rollback handhaben. Eine nur mit JavaScript oder CSS geänderte Renderer-Implementierung folgt einem anderen Weg. Die Hosting-Beschränkungen spielen auch eine Rolle: Ein kleiner GitHub-hosteter Projekt benötigt nicht die gleichen Release-Kontrollen wie ein Enterprise-Distributionsservice.

Für Projekte, die Electron-Builder mit signierter Artefaktveröffentlichung verwenden, ist electron-updater in der Regel die praktische Standardlösung. Sein Ökosystem umfasst Veröffentlichungsziele, Release-Manifeste, Artefakt-Downloads und die Installation bei der nächsten Startphase. Es unterstützt mehrere Hosting-Modelle, aber Ihr Team besitzt immer noch die Verantwortung für das Signieren, die Verfügbarkeit der Feed, die Kanalpolitik, die Rollout-Kontrollen und die Überwachung. Die Elektron-Updater-Integration für __CAPGO_KEEP_0__ Electron updater integration for Capgo sieht Teams, die eine kleine Integration um __CAPGO_KEEP_0__ Releases bevorzugen. Sie überprüft bei der Startphase und dann auf einem wiederkehrenden Intervall, was die Konfiguration einfach hält, aber weniger Raum für eine fortgeschrittene Kanalwahl, gestaffelte Traffic und benutzerdefinierte Rückschaltregeln lässt. Das Paket ist für einen kleinen Release-Prozess angemessen, vorausgesetzt, dass __CAPGO_KEEP_1__ Releases und seine Verfügbarkeit Ihren Betriebsanforderungen entsprechen.

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.

Ausfallsicherheit ist ein selbst erstellter Dienst wie Hazel, Nuts oder ein interner Feed, wenn die Freigabeberechtigung, die Zielsetzung für den Kunden, die Protokollierung von Audit-Ereignissen oder die geregulierten Bereitstellungsregeln die Implementierungskosten rechtfertigen. Der Kompromiss ist die laufende Verantwortung. Ihr Team muss die Semantik der Manifestdatei definieren, die Signierungs-Schlüssel schützen, die Client-Kompatibilität aufrechterhalten und die fehlgeschlagenen Downloads, abgelehnten Releases und die Rollback-Verhaltensweise testen.

Live-Updates können nur Renderer-Änderungen ohne Neubau des nativen Shells ausliefern. Sie ersetzen keine binären Updates, wenn Electron, native Module, Berechtigungen oder die Verhaltensweise des Installers geändert werden. Verwenden Sie electron-updater, es sei denn, Sie benötigen eine benutzerdefinierte Rollout-Logik. Benötigen Sie eine benutzerdefinierte Logik, bauen Sie sich um die etablierten Manifest- und Artefaktkonventionen, anstatt das Herunterladen und die Differenz-Update-Verhaltensweise neu zu erstellen. Ein zuverlässiger Weg ist der, den Ihr Team beobachten, auf die Bühne bringen und rückgängig machen kann.

Implementierung des Auto-Update-Flusses im Hauptprozess

Der Hauptprozess sollte die Update-Überprüfungen und -Installationen besitzen. Der Renderer kann den Status anzeigen, aber er sollte nicht entscheiden, ob ein ausführbares Update vertrauenswürdig ist oder wann die Anwendung beendet wird.

Konfigurieren Sie das Veröffentlichungsziel zuerst

Ein minimaler electron-builder-Konfiguration könnte wie folgt aussehen:

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

Halten Sie Beta- und Stable-Feeds getrennt. Ein Kanal ist eine Freigabe-Politik und nicht ein Label in der Benutzeroberfläche. Jeder Kanal sollte auf die richtige signierte Artefakt- und Manifestdatei auflösen.

Planen Sie die Überprüfungen und offenbaren Sie die Lebenszyklusereignisse

Aufrufen checkForUpdates() Ein häufiger Produktionsfehler ist nur während des Startvorgangs. Ein Benutzer kann das Anwendungsprogramm über Tage hinweg offen lassen, sodass der Hauptprozess einen kontrollierten Intervall und eine Wiederholungsstrategie benötigt, die Offline-Betrieb respektiert.

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

Die genaue Verhaltensweise des Update-Ereignisses variiert je nach Plattform und Paketierungsaufbau, daher sollten Sie aus installierten Artefakten testen und nicht aus Entwicklungsmode. Die Dokumentation von Electron weist auch auf Startzeitbedenken auf Windows hin, einschließlich des Squirrel-First-Run-Falls. Lassen Sie den Update-Check nicht vor dem Abschluss der plattform-spezifischen Initialisierung auslösen, die das Anwendungsprogramm benötigt.

Halten Sie den Renderer ohne Blockierung informiert.

Die Präloadder Brücke sollte eine enge API offenlegen:

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

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

Ein Renderer-Seitiger Fortschrittsbalken kann absichtlich einfach bleiben:

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

Blockieren Sie die Installation hinter Benutzerzustimmung in der Produktion, es sei denn, Ihr Anwendungsprogramm hat einen starken Grund, sofort neu zu starten. Setzen Sie einen isQuitting Flag vor quitAndInstall(), weil normale Fenster-Schließen-Handler sonst verhindern können, dass der Installer die Kontrolle übernimmt.

Zwei Fehlschläge verdienen explizite Tests. Zuerst muss ein bereits laufender Client auf einem Zeitplan aufrufen, nicht nur bei der Startphase. Zweitens muss das checkForUpdates() Ereignis die Protokollierung und die Telemetrie erreichen. Wenn das Anwendungsprogramm das Ereignis ohne Berichterstattung verschluckt, dann error sind Ihre App-Fehlersuche-Workflow beginnt mit Vermutungen anstatt mit Beweisen.

Wiring von CI/CD für signierte Releases und Manifeste

Die Releasepipeline ist die Wahrheit für das, was die Benutzer installieren. Ein lokales Build, das auf einem Entwicklerrechner funktioniert, beweist nicht, dass das veröffentlichte Binär, Manifest, Signatur und Kanal alle dasselbe Release beschreiben.

Electron-builder’s Veröffentlichungsmodell erwartet, dass die Release-Metadaten und der Update-Zielwert gemeinsam reisen. Für viele Konfigurationen bedeutet dies ein Artefakt wie latest.yml für Windows und latest-mac.yml für macOS, neben plattform-spezifischen Paketen und Blockmap-Dateien. Ein fehlendes Manifest kann ein perfekt gültiges Binär unsichtbar für Clients machen.

Mach das Signieren explizit in CI

Eine vereinfachte GitHub Actions-Muster sieht wie folgt aus:

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

Verwende plattform-spezifische Geheimnisse und halte das Signiermaterial außerhalb des Repositorys. Ein Signierfehler sollte den Job stoppen, nicht einen ungesicherten Ausfall produzieren, den jemand manuell hochlädt.

Die Veröffentlichungskonfiguration sollte den Anbieter und den Kanal konsistent identifizieren:

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

Bevor die Veröffentlichung erfolgt, sollte die Aufgabe anhand der Paketversion, der Etiketten, des Commit-SHA und des Rauchtest-Ergebnisses gesperrt werden. Nach der Veröffentlichung sollte überprüft werden, dass der Feed die erwartete Manifest enthält und dass das Manifest auf das genaue Artefakt verweist, das durch diese Aufgabe erzeugt wurde. Die Anleitung zur kontinuierlichen Integration ist nützlich, wenn Sie die Überprüfungen formalisieren und Teams, die die Pipeline-Orchestrierung vergleichen, auch von der Verwendung von Jenkins und Ansible profitieren können, wenn Sie wissen, wann Sie sie zusammen verwenden sollten Die Befehle, die häufig ein unvollständiges Release offenlegen, sind absichtlich langweilig:.

Diese Überprüfungen ersetzen keine signierte Installationstest. Sie fangen jedoch den operativen Fehler ein, ein Binär ohne die erforderlichen Metadaten hochzuladen, die die Clients benötigen, um es zu entdecken.

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

Die kontinuierliche Integration-Anleitung

Rollouts, Kanäle und Rollover-Strategie

Eine Release-Feed sollte sich mehr wie ein Ziel für die Bereitstellung als ein Download-Ordner verhalten. Halten Sie intern, beta, und neueste Kanäle getrennt, wobei jeder Kanal durch seinen eigenen Manifest und signierten Artefakt-Set unterstützt wird. Die Promotion sollte eine getestete Release zwischen Richtlinien verschieben, nicht eine Datei während Clients sie herunterladen, überschreiben.

Die Trennung der Kanäle schützt auch die Produktion vor ungewollten Testbuilds. Der Updater sollte wissen, ob ein Client zu einer internen Gruppe, einer Beta-Gruppe oder der stabilen Bevölkerung gehört, bevor er die Feed bewertet.

Verwenden Sie Gruppen vor breiter Veröffentlichung

Eine benutzerdefinierte Manifest-Feld kann eine gestufte Lieferung ausdrücken:

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

Der Hauptprozess kann eine stabile pro-User-Tasche zuweisen, dann vergleichen Sie diese Tasche mit rolloutPercentage. Die stabile Zuweisung ist wichtig. Ein Benutzer, der zwischen berechtigten und unzulässigen Zuständen auf jeder Überprüfung wechselt, erhält unvorhersehbares Verhalten und macht die Unterstützungsberichte schwierig zu interpretieren.

Erweitern Sie die Kohorte nur, nachdem die Veröffentlichung ihr Beobachtungsfenster überlebt hat. Das genaue Fenster sollte Ihren Nutzungsmuster entsprechen, aber die Entscheidung sollte auf Signale, nicht auf einen Kalender allein, basieren. Erfassen Sie Ergebnisse von Update-Überprüfungen, Download-Abgeschlossenheit, Startgesundheit, Crashes, Renderer-Ausnahmen und Authentifizierungs-Erfolge.

Verwirre nicht die Rücksetzung mit der Löschung eines Artefakts. Bestehende Kunden haben möglicherweise gecachte Metadaten, und einige laufen möglicherweise bereits mit der schlechten Version. Ein Rücksetzungsplan benötigt eine vorherige unterschriebene Veröffentlichung, eine Änderung der Feed und eine Clientverhalten, das sich wiederherstellen kann.

Betriebsregel: Rücksetzungen müssen von dem im Notfall eingesetzten Ingenieur ohne Wiederaufbau der Anwendung durchgeführt werden können.

In der Praxis sollte das Runbook die vorherige Veröffentlichungsmanifest zurück auf das betroffene Kanal befördern, den Staging-Marker invalidieren und bestätigen, dass neue Checks auf die sichere Version auslaufen. Wenn das Problem im Renderer code und nicht im native Shell liegt, kann eine gezielte Web-layer-Rücksetzung schneller sein. Eine Plattform wie code Phased Rollouts kann für das separate Lieferungsschicht relevant sein, sollte aber die Grenze zwischen einer native Binär-Rücksetzung und einer Web-Bundle-Rücksetzung nicht verschleiern. Capgo phased rollouts Ein Electron-Updater lädt ausführbare __CAPGO_KEEP_0__ herunter und kann sie mit wenig Benutzerinteraktion installieren. Das macht den Updatepfad zu einer

__CAPGO_KEEP_0__-phasierter Rollouts

An Electron updater downloads executable code and can install it with little user interaction. That makes the update path a Security-Grenze, nicht nur eine Convenience-Funktion. Die offizielle Dokumentation von Electron beschreibt Plattformbeschränkungen wie macOS ATS, und die Sicherheitsabdeckung hat ein Szenario aus dem Jahr 2022 dokumentiert, in dem Angreifer, die die Update-Infrastruktur kontrollierten, schädliche Pakete bereitstellen konnten, die den code-Signierungsprüfungen noch immer standhielten, wie im Die __CAPGO_KEEP_0__-Signierung bleibt grundlegend, aber sie ist nicht das gesamte Vertrauensmodell. Signieren Sie jeden Release, überprüfen Sie das Zertifikat und die Identität während der CI und führen Sie eine dokumentierte Schlüsselrotation durch. Bei macOS kombinieren Sie das Signieren mit der Notarisation und der sicheren Ausführung, die Ihrem Anwendungsfall entspricht. Bei Windows stellen Sie die Zertifikatsbesitzerschaft, die Erneuerung und den Zugriff auf die Build-Dateien auditorsicher. Linux benötigt eine distributionsspezifische Strategie, da Electron keine universelle Updater-Implementierung bietet..

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.

Ein signiertes Binärdatei kann immer noch mit dem falschen Release verbunden sein, wenn die Metadatenkanal kompromittiert oder falsch konfiguriert ist. Überlegen Sie, eine Manifestsignatur zu erstellen, die gegen einen öffentlichen Schlüssel im Anwendungscode verifiziert wird, ein Mindestzulässiges Versionsniveau zu erzwingen und unerwartete Downgrades, es sei denn, ein autorisierter Wiederherstellungsverfahren erlaubt sie explizit.

Der Feed verdient auch Produktionskontrollen:

Beschränken Sie den Zugriff auf Veröffentlichungen:

• Erteilen Sie der CI nur die erforderlichen Berechtigungen, um Release-Assets zu veröffentlichen. Schützen Sie Signiergeheimnisse:
• Halten Sie Zertifikate und private Schlüssel in verwaltetem geheimen Speicher, nicht in Repository-Dateien. Schützen Sie die Metadaten genauso sorgfältig wie das Binärdatei
• Abhängigkeiten festlegen: Locken Sie Electron, electron-builder und transitive Abhängigkeiten in der CI.
• Review der Artefakte: Überprüfen Sie die generierten Pakete und vergleichen Sie sie mit der beabsichtigten Commit- und Version.
• Sichere Transportanforderungen erfüllen: Folgen Sie den ATS- und den strengen HTTPS-Anforderungen für die Update-Anfragen.
• Fehler bei der Überprüfung überwachen: Behandeln Sie wiederholte Signatur- oder Manifestfehler als Sicherheitsereignisse und nicht als gewöhnliches Netzwerkgeräusch.

Electrons gepflegtes Werkzeug-Ökosystem fügt sich weiterhin der Verpackung und dem Updater-coverage hinzu, aber die Wartung entfernt nicht die Notwendigkeit für die Bedrohungsbewertung. Das praktische Ziel besteht darin sicherzustellen, dass ein Angreifer, der eine Bucket, einen CDN oder einen Build-Schritt kompromittiert, den Client trotzdem nicht dazu bringen kann, eine unbefugte Veröffentlichung anzunehmen. Die Signatur-Überprüfung-Richtlinie bietet wertvolle Kontextinformationen für die Gestaltung dieses zusätzlichen Überprüfungsstapels.

Die Produktionsupdate-Runbook und -Checkliste

Ein Release ist erst fertig, wenn ein anderer Ingenieur es unter Druck bedienen kann. Halten Sie die Checkliste in der Nähe des Bereitstellungsjobs und des Notfallkanals.

Vorfreisegrenzen

• Versionen identifizieren: Bestätigen Sie die Paketversion, Release-Tag, Commit-SHA und Changelog übereinstimmen.
• Signieren: Überprüfen Sie, ob alle Plattform-Artikel signiert sind und die Notarisation oder eine äquivalente Validierung abgeschlossen wurde.
• Manifestvertrag: Bestätigen Sie latest.yml, latest-mac.yml, Hashes, Pfade und Blockmaps stimmen mit den hochgeladenen Artefakten überein.
• Sicherheit des Kanals: Veröffentlichen Sie vor der Promotion des Release-Kanals auf den internen oder Beta-Feed.
• Telemetrie: Bestätigen Sie die Überprüfung von Updates, den Download-Progress, die Installationsabgeschlossenheit und die Gesundheit beim Start sowie Fehlermeldungen, die eintreffen.

Canary- und Vollrollout

• Kohortenkontrolle: Mit einer absichtlich kleinen internen oder Beta-Audienz beginnen.
• Gesundheitsbudget: Die Veröffentlichung zurückhalten, wenn Launch-Fehler, Download-Fehler für Updates, Renderer-Ausnahmen oder Authentifizierungsfehler die von der Mannschaft genehmigten Grenzen überschreiten.
• Zustimmung zur Veröffentlichung: Eine explizite Ja- oder Nein-Entscheidung erfordern, bevor die Veröffentlichung in den stabilen Feed übertragen wird.
• Kundeneinfluss: Unterstützungsmeldungen vor der breiten Verteilung vorbereiten, nicht nach dem ersten Vorfall.

Reaktion auf Vorfälle

Wenn das neue Binärprogramm nicht startet, der Prozess startet nicht oder die Updates nicht vollständig heruntergeladen werden, stoppen Sie die Werbung sofort. Setzen Sie die vorherige signierte Manifestdatei wieder her, deaktivieren Sie den Staging-Marker und überprüfen Sie, ob die frischen Clients auf die vorherige Version zugreifen können. Überprüfen Sie dann mit der Telemetrie, ob die Flotte wiederhergestellt ist, bevor Sie die Schließung mitteilen.

Die genauen Rollback-Befehle hängen von Ihrem Anbieter ab, aber die Sequenz sollte immer dokumentiert sein: Flippen Sie das Kanalmanifest auf die vorherige Version, deaktivieren Sie den Staging-Tag, setzen Sie einen gezwungenen Update-Marker, wenn eine Wiederherstellung erforderlich ist, und überprüfen Sie den Downgrade-Weg mit der Live-Telemetrie.Ein nicht getesteter Rollback ist nur ein Wunsch.

Capgo bietet einen Electron-Updater für die Bereitstellung von signierten Web-Schichten, gezielten Kanälen, Rollout-Kontrollen und Update-Beobachtbarkeit ohne das Neubauen der nativen Shell für jeden Renderer-Wechsel. Wenn Sie native Binärprogramme von kontrollierten JavaScript- und CSS-Delivery trennen möchten, besuchen Sie Capgo und bewerten Sie es neben Ihrem bestehenden Electron-Release-Pipeline.