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

Sie haben das Elektron-Build abgeschickt, die Veröffentlichungsseite ist online 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 immer noch mit einem alten Binär mit einem gebrochenen Authentifizierungsfluss, während Ihre Protokolle fast nichts Nützliches zeigen.

Das ist die unangenehme Realität von Elektron-App-Auto-Update. Die Aktualisierungssoftware API ist nur ein Komponente. Eine Produktionsversion hängt auch von der Plattformsignierung, der Transportpolitik, den Manifesten, der Hosting, den Lebenszyklusereignissen, der Beobachtbarkeit, den Rollout-Kontrollen und einem Rückrufpfad ab. Behandeln Sie jede dieser Optionen als verpflichtend und ein Routine-Patch kann zu einem Nacht-Alarme werden.

Inhaltsübersicht

• Der 2-Uhr-Update-Incident, das diese Anleitung ausgelöst hat
• Wählen Sie den richtigen Weg für die Elektron-Aktualisierung
• Implementieren Sie den Auto-Update-Flow 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
  • Machen Sie die Signierung explizit in CI
• Rollouts, Kanäle und Rollback-Strategie
  • Verwenden Sie Cohorten vor breiter Auslieferung
• Auto-Update als Sicherheitskontrolle behandeln
  • Die Metadaten so sorgfältig schützen wie das Binärdatei
• Das Produktionsupdate-Handbuch und -Checkliste
  • Prärelease-Schranken
  • Kanarische und volle Auslieferung
  • Reaktion auf Vorfälle

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 unsignierten Electron-Build hochgeladen, und die Veröffentlichungslaufwerk 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 einem installierten Produktionsbuild ausgetestet.

Um 2:08 Uhr meldete PagerDuty den aufgerufenen Ingenieur. Ein neuer Authentifizierungsfluss war für einen Teil der Flotte fehlgeschlagen, und Benutzer, die das Update erhalten hatten, konnten die Anmeldung nicht abschließen. Andere Benutzer blieben bei der vorherigen Version, da 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. Das Binärdatei existierte, aber die erwartete Metadaten stellten nicht klar dar, welche Clients sie erhalten sollten. Ein Manifest ist ein Vertrag zwischen der Releasepipeline und den installierten Clients, nicht eine optional Upload-Detail.
2. Überprüfen Sie die Signierung. Die Veröffentlichung 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 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 Version abzuwenden.

Die offizielle Dokumentation von Electron macht die Plattformgrenzen klar. Linux hat keine integrierte Unterstützung für die automatische Aktualisierung.und 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 die Überprüfung der Veröffentlichung. Die Electron autoUpdater-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-Installationsvorhaben mit fehlender Telemetrie.

Der Aufwand reichte über die Zeit hinaus, die für die Entwicklung aufgewendet wurde. 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 Clientvertrag, Rollout-Kanäle begrenzen die Auswirkungen und Rollback bleibt ein getesteter Weg anstatt eine Notlösung.

Die Wahl des richtigen Electron-Updater-Pfads

Bei 2 Uhr morgens wird die falsche Updater-Wahl zu einem Betriebssystemproblem. Eine native Binär-Update muss die 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 Unternehmen, das eine Verteilungsdienstleistung anbietet.

For Projekten, die Electron-Builder mit signierter Artefaktveröffentlichung verwenden, electron-updater ist 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 Electron-Update-Integration für Capgo ist relevant, wenn ein hybrides Liefermodell für Web-Schichtenbündel neben native Releases bewertet wird.

update-electron-app passt sich Teams an, die eine kleine Integration um GitHub Releases bevorzugen. Es überprüft bei der Startphase und dann auf einem wiederkehrenden Intervall, was die Konfiguration einfach hält, aber weniger Raum für die Auswahl von fortgeschrittenen Kanälen, für die Verwaltung von Stufenverkehr und für benutzerdefinierte Rückschlagsregeln lässt. Das Paket ist für einen kleinen Release-Prozess angemessen, vorausgesetzt, dass GitHub Releases und seine Verfügbarkeit Ihren betrieblichen Anforderungen entsprechen.

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 geregeltete Bereitstellung von Regeln die Implementierungskosten rechtfertigen. Der Handelsoption 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.

Lebendige Updates können nur Renderer-Änderungen ohne Wiederaufbau des nativen Shells versenden. 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. Wenn benutzerdefinierte Logik erforderlich ist, bauen Sie um die etablierten Manifest- und Artefaktkonventionen herum, anstatt das Herunterladen und das Differenz-Update-Verhalten 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

Anrufung checkForUpdates() Ein häufiger Produktionsfehler ist nur während des Startvorgangs. Ein Benutzer kann die Anwendung über Tage 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 Verpackungssetup, daher sollten Sie aus installierten Artefakten testen und nicht in Entwicklungsbetrieb. 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 die Anwendung benötigt.

Halten Sie den Renderer informiert, ohne die Arbeit zu blockieren.

Die Präloade-Brücke sollte eine enge API aussetzen:

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

Installieren Sie die Installation hinter Benutzerzustimmung in der Produktion, es sei denn, Ihre Anwendung hat einen starken Grund, sofort neu zu starten. Setzen Sie ein isQuitting Zeichen vorher quitAndInstall()weil normale Fenster-Schließen-Handler sonst die Installation daran hindern können, die Kontrolle zu übernehmen.

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 die App das Ereignis ohne Berichterstattung verschluckt, dann error sind Ihre Tests fehlerhaft. 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. Eine lokale Build, die auf einem Entwickler-Computer funktioniert, beweist nicht, dass das veröffentlichte Binär, das Manifest, die Signatur und der Kanal alle dasselbe Release beschreiben.

Electron-builder's Publish-Modell erwartet, dass die Release-Metadaten und die Update-Zielgruppe zusammen 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 einen perfekt gültigen Binär unsichtbar für Clients machen.

Stelle das Signieren explizit in CI

Eine vereinfachte GitHub Actions-Pattern 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 Fallback erzeugen, 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 Tag, der 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 generiert wurde. Die 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 Befehle, die häufig ein unvollständiges Release offenlegen, sind absichtlich langweilig:

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 einem signierten Artefakt-Set unterstützt wird. Die Promotion sollte eine getestete Version zwischen den Richtlinien verschieben, nicht eine Datei während der Clients sie herunterladen, überschreiben.

Die Trennung der Kanäle schützt auch die Produktion vor ungewollten Testversionen. 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-Nutzer-Tasche zuweisen, dann vergleichen Sie diese Tasche mit rolloutPercentage. Die stabile Zuweisung ist wichtig. Ein Benutzer, der zwischen den berechtigten und nicht berechtigten 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 und nicht auf einen Kalender allein basieren. Erfassen Sie Ergebnisse von Update-Überprüfungen, Download-Abgeschlossenheit, Startgesundheit, Crashs, Renderer-Ausnahmen und Authentifizierungserfolge.

Verwirre nicht Rollback mit der Löschung eines Artefakts. Bestehende Kunden haben möglicherweise gecachte Metadaten, und einige laufen möglicherweise bereits mit der schlechten Version. Ein Rollback-Plan benötigt eine vorherige signierte Veröffentlichung, eine Änderung der Feed und eine Client-Verhaltensweise, die sich wiederherstellen kann.

Betriebsregel: Rollback muss von dem im Notfall eingesetzten Ingenieur ohne Wiederaufbau der Anwendung während des Vorfalls 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-Rollback schneller sein. Eine Plattform wie code Phased Rollouts kann für das separate Lieferungsschicht relevant sein, sollte aber die Grenze zwischen einem native Binär-Rollback und einem Web-Bundle-Rollback 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

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 Elektron-Builder-Auto-Update-Sicherheitsdokumentation.

Code-Signierung bleibt grundlegend, aber es 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 Zertifizierungseigentümerschaft, die Erneuerung und den Zugriff auf die Build-Dateien auditorsicher ein. Linux benötigt eine distributionsspezifische Strategie, da Electron keinen universalen Updater bereitstellt.

Schützen Sie die Metadaten genauso sorgfältig wie das Binärdatei

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 ein öffentliches Schlüssel in der Anwendung verifiziert wird, ein Mindestzulassungslevel festzulegen und unerwartete Downgrades nur dann zuzulassen, wenn ein autorisierter Wiederherstellungsverfahren sie explicit erlaubt.

Der Feed verdient auch Produktionskontrollen:

• Einschränken Sie den Zugriff auf das Veröffentlichen: Stellen Sie sicher, dass die CI nur die erforderlichen Berechtigungen hat, um Release-Assets zu veröffentlichen.
• Schützen Sie die Signierungsschlüssel: Halten Sie Zertifikate und private Schlüssel in einem verwalteten geheimen Speicher, nicht in Repository-Dateien.
• Abhängigkeiten festlegen: Locken Sie Electron, electron-builder und transitive Abhängigkeiten in der CI.
• Review von Artefakten: Überprüfen Sie die generierten Pakete und vergleichen Sie sie mit der beabsichtigten Commit- und Version.
• Sichere Transportversorgung anfordern: Folgen Sie den ATS- und strengen HTTPS-Anforderungen für Update-Anfragen.
• Überwachung von Fehlern bei der Verifizierung: Behandeln Sie wiederholte Signatur- oder Manifestfehler als Sicherheitsereignisse, nicht als gewöhnliches Netzwerkgeräusch.

Electrons aufrechterhaltene Werkzeuglandschaft für die Paketerstellung und -aktualisierung setzt sich fort, 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 Signaturverifizierungsanleitung bietet wertvolle Kontextinformationen für die Gestaltung dieses zusätzlichen Verifizierungsschicht.

Die Produktionsupdate-Runbook und -Checkliste

Ein Release ist nur dann 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 ist.
• 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 Voll-Rollout

• Kohorten-Kontrolle: Mit einer absichtlich kleinen internen oder Beta-Audienz beginnen.
• Gesundheitsbudget: Die Veröffentlichung zurückhalten, wenn Launch-Fehler, Update-Download-Fehler, Renderer-Ausnahmen oder Authentifizierungsfehler die von der Mannschaft genehmigten Grenzen überschreiten.
• Zustimmung zur Veröffentlichung: Eine explizite Ja- oder Nein-Entscheidung vor der Weiterleitung der Veröffentlichung an die stabile Feed erfordern.
• Kundeneinfluss: Unterstützungsmeldungen vor der breiten Verbreitung vorbereiten, nicht nach dem ersten Vorfall.

Reaktion auf Vorfälle

Wenn das neue Binärprogramm nicht startet, die Prozessauflistung fehlschlägt oder die Updates nicht vollständig heruntergeladen werden, stoppen Sie die Promotion sofort. Setzen Sie die vorherige signierte Manifestdatei wieder her, invalidieren Sie den Staging-Marker und überprüfen Sie, ob die frischen Clients auf die vorherige Version zurückgegriffen werden. Dann bestätigen Sie durch Telemetrie, dass die Flotte sich wieder erholt, bevor Sie die Schließung mitteilen.

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

Capgo offers an Electron updater for delivering signed web-layer changes, targeted channels, rollout controls, and update observability without rebuilding the native shell for every renderer change. If you want to separate native binary releases from controlled JavaScript and CSS delivery, visit Capgo und bewerten Sie es neben Ihrem bestehenden Electron-Release-Pipeline.