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

Sie haben den Elektron-Build verschifft, die Release-Seite ist live und die erste Support-Anfrage kommt, bevor der Kaffeeautomat fertig ist. Ein Benutzer sagt, die App habe die Aktualisierung nie gefunden. Ein anderer hat sie heruntergeladen, kann sie aber nicht installieren. Ein Dritter läuft noch mit einem alten Binary und einem gebrochenen Authentifizierungsfluss, während Ihre Logs fast nichts Nützliches zeigen.

Dass ist die unangenehme Realität von Elektron-App-Automatische Aktualisierung. Der Updater API ist nur ein Komponente. Eine Produktionsfreigabe hängt auch von der Plattformsignatur, der Transportpolitik, den Manifesten, der Hosting, den Lebenszyklusereignissen, der Beobachtbarkeit, den Rollout-Kontrollen und einem Rückrufpfad ab. Behandeln Sie jede dieser Komponenten als optional und ein Routine-Patch kann zu einer Nacht-Alarme-Situation werden.

Inhaltsverzeichnis

• Die 2-Uhr-Update-Vorfälle, die diese Anleitung ausgelöst haben
• Der 2-Uhr-Update-Incident, das diese Anleitung ausgelöst hat
• Wählen Sie den richtigen Elektron-Updater-Path
  • Konfigurieren Sie das Veröffentlichungsziel zuerst
  • Konfigurieren Sie das Veröffentlichungsziel zuerst
  • Informiere den Renderer ohne den Arbeitsfluss zu blockieren
• Wiring von CI/CD für signierte Releases und Manifeste
  • Stellen Sie das Signieren explizit in CI ein
• Rollouts, Kanäle und Rollback-Strategie
  • Verwenden Sie Cohorten vor breiter Aussetzung
• Auto-Update als Sicherheitskontrolle behandeln
  • Schützen Sie die Metadaten genauso sorgfältig wie das Binärdatei
• Das Produktionsupdate-Handbuch und -Checkliste
  • Prärelease-Gates
  • Canary- und Vollrollout
  • Reaktion auf Vorfälle

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

Die Veröffentlichung hatte CI durchlaufen und sah normal aus. Am späten Freitag stellte ein Entwickler einen ungesicherten Electron-Build bereit, und der Veröffentlichungsauftrag lud genügend Assets hoch, um die Veröffentlichung vollständig erscheinen zu lassen. Die Anwendung wurde in der Testumgebung gestartet, aber niemand hatte den Updatepfad von einem installierten Produktionsbuild ausgetestet.

At 2:08 Uhr morgens meldete PagerDuty den aufgerufenen Ingenieur. Eine neue Authentifizierungsablauf schlug für einen Teil der Flotte fehl, und Benutzer, die die Aktualisierung erhalten hatten, konnten den Anmeldungsprozess 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 gebrochene Version, während der Rest der Flotte eine andere Version mit keiner klaren Erklärung lief.

Die Ermittlung folgte fünf Kontrollen:

1. Überprüfe die Release-Feed. 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 optionalen Upload-Detail.
2. Überprüfe die Signatur. Die Release wurde nicht korrekt signiert, sodass die Überprüfung auf betroffenen Plattformen fehlschlug. Die Signatur muss die Veröffentlichung blockieren, wenn sie fehlt oder ungültig ist.
3. Vergleiche die Client-Protokolle. Die Aktualisierungsfehler erreichten nie die zentrale Telemetrie. Die Anwendung verschluckte das Ereignis und lief weiter, sodass das Team ohne zuverlässige Beweise blieb.
4. Überprüfe die Rollout-Kontrollen. Es gab keine internen Kanäle oder geschalteten Kohorten. Alle berechtigten Clients verwendeten denselben Feed, sodass die Fehlschläge ohne ein Enthaftungspunkt ausbreiteten.
5. Suche nach einer Rückschaltung. Das Team hatte keine getestete Verfahren, um die vorherige Version neu zu veröffentlichen oder die Clients von der gebrochenen Version abzulenken.

Elektrons offizielles Dokumentation macht die Plattformgrenzen klar. Linux has no built-in auto-updater support, und macOS-Update-Anfragen müssen zufriedenstellen Sicherheitsanforderungen für App TransportDie Dokumentation identifiziert auch das Signieren als Voraussetzung für zuverlässige macOS-Updates und die Überprüfung der Veröffentlichung. Elektron autoUpdater-Dokumentation definiert die API Einschränkungen, während das Release-System die umgebenden Betriebssteuerungen durchsetzen muss.

Postmortem-Lektion: Ein Updater, der nicht erklären kann, was passiert ist, ist ein fehlender Telemetriedatensatz bei einer Remote-Installation.

The cost extended beyond engineering time. Customers lost confidence in the desktop client, support had to explain inconsistent behavior, and the team spent the next workday rebuilding a release process that should have existed before the incident.

Automatisches Update Betriebssystem. Die Signierung ist ein Release-Gateway, Manifeste definieren den Client-Vertrag, Rollout-Kanäle begrenzen die Exposition und Rollback bleibt ein getesteter Weg anstatt eine Notlösung.

Die Wahl des richtigen Electron-Update-Wegs

Um 2 Uhr morgens wird die falsche Update-Wahl zu einem Betriebsproblem. Ein natives Binärupdate muss die Signierung, Manifeste, Installationsprogramme und Rollback handhaben. Ein nur auf JavaScript oder CSS basierendes Renderer-Update folgt einem anderen Weg. Auch die Hosting-Beschränkungen spielen 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 signierten Artefakt-Publikationen verwenden electron-updater ist in der Regel die praktische Standardauswahl. Sein Ökosystem umfasst Veröffentlichungsziele, Release-Manifeste, Artefakt-Downloads und Installationen bei der nächsten Startphase. Es unterstützt mehrere Hosting-Modelle, aber Ihr Team besitzt immer noch die Signierung, die Verfügbarkeit der Feed, die Kanalpolitik, die Rollout-Kontrollen und die Überwachung. Das Electron-Update-Integration für Capgo ist relevant, wenn ein hybrider Liefermodell für Web-Schichtenpakete neben nativen Releases bewertet wird.

update-electron-app passt sich Teams an, die eine kleine Integration um GitHub Releases wollen. 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, gestaffelte Traffic und benutzerdefinierte Rollback-Regeln lässt. Das Paket ist für einen kleinen Release-Prozess angemessen, vorausgesetzt, GitHub Releases und seine Verfügbarkeit entsprechen Ihren Betriebsanforderungen.

Eine benutzerdefinierte Dienst wie Hazel, Nuts oder ein interner Feed passt, wenn die Freigabeberechtigung, die Zielgruppenzielgerichtete, die Protokolle oder die geregulierten Bereitstellungsvorschriften den Implementierungskosten gerecht werden. Der Gegenseitigkeitswert ist die laufende Eigentümerschaft. Ihr Team muss die Manifestsemantik definieren, die Signierungschlüssel schützen, die Clientkompatibilität aufrechterhalten und die fehlgeschlagenen Downloads, die abgelehnten Releases und die Rollbackverhalten testen.

Live-Updates können nur Renderer-Änderungen ohne Wiederaufbau des native Shell schicken. Sie ersetzen keine Binärupdates, wenn Electron, native Module, Berechtigungen oder Installationsverhalten geändert werden. Use electron-updater unless you need custom rollout logic. Wenn benutzerdefinierte Logik erforderlich ist, bauen Sie sich um die etablierten Manifest- und Artefaktkonventionen, anstatt das Herunterladen und das Differenzial-Updateverhalten neu zu erstellen. Ein zuverlässiger Weg ist der, den Ihr Team beobachten, auf die Bühne bringen und rückgängig machen kann.

Implementieren Sie den Auto-Update-Flow im Hauptprozess

Der Hauptprozess sollte die Updateprü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

Eine minimale 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 Stabil-Feeds getrennt. Ein Kanal ist eine Veröffentlichungsrichtlinie und nicht ein Label in der Benutzeroberfläche. Jeder Kanal sollte auf die richtige signierte Artefakt- und Manifestdatei auflösen.

Planen Sie Überprüfungen und exposen Sie Lebenszyklusereignisse

Aufrufen checkForUpdates() only during startup is a common production mistake. A user can leave the application open for days, so the main process needs a controlled interval and a retry strategy that respects offline operation.

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

Erstes Aufrufen nur während des Startvorgangs ist ein häufiger Produktionsfehler. Ein Benutzer kann das Anwendungsprogramm über Tage offen lassen, daher benötigt der Hauptprozess einen kontrollierten Interval und eine Wiederholungsstrategie, die Offline-Betrieb respektiert.

Informiere den Renderer ohne den Arbeitsfluss zu blockieren

Die Präloaderbrü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');
  }
});

Die Präloaderbrücke sollte eine enge __CAPGO_KEEP_0__ aussetzen:

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

Installation hinter Benutzereinwilligung in der Produktion, es sei denn, Ihre Anwendung hat einen starken Grund, sofort neu zu starten. Setzen Sie einen isQuitting Flagge vorher quitAndInstall()weil normaler Fenster-Schließen-Handler sonst verhindern können, dass der Installer die Kontrolle übernimmt.

Zwei Fehler verdienen explizite Tests. Zuerst muss ein bereits laufender Client checkForUpdates() Wiring CI/CD für signierte Releases und Manifeste error Der Ereignis muss die Protokolle und die Telemetrie erreichen. Wenn die App es ohne Meldung verschluckt, Anwendungsentwicklungsablauf für Fehlerbehebung beginnt mit Vermutungen anstatt mit Beweisen.

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

The release pipeline is the source of truth for what users install. A local build that works on one developer’s machine doesn’t prove that the published binary, manifest, signature, and channel all describe the same release.

Electron-Builder verwendet ein Publish-Modell, das die Veröffentlichungsdaten und das Updateziel gemeinsam transportiert. Für viele Konfigurationen bedeutet dies, dass 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 vollständig gültiges Binärdatei für Kunden unsichtbar machen.

Machen Sie das Signieren explizit in CI

Ein vereinfachtes GitHub Actions-Muster sieht so 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

Verwenden Sie plattformspezifische Geheimnisse und halten Sie das Signiermaterial außerhalb des Repositorys. Ein Signierfehler sollte den Job nicht beenden, sondern keine ungesicherte Fallback-Datei erzeugen, die 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"
    }
  }
}

Before publication, gate the job on the package version, tag, commit SHA, and smoke-test result. After publication, verify that the feed contains the expected manifest and that the manifest points to the exact artifact generated by that job. The Integrationsanpassungsrichtlinie wird nützlich, wenn Sie diese Überprüfungen formalisieren, und Teams, die Pipeline-Orchestrierung vergleichen, können auch von einem Verständnis profitieren Wann Jenkins und Ansible gemeinsam verwenden.

Die Befehle, die häufig eine unvollständige Veröffentlichung offenlegen, sind absichtlich langweilig:

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

Diese Überprüfungen ersetzen keinen signierten Installations-Test. Sie fangen jedoch den operativen Fehler ein, einen Binär ohne die erforderlichen Metadaten hochzuladen, die Clients benötigen, um es zu entdecken.

Rollouts, Kanäle und Rollover-Strategie

Ein 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 Veröffentlichung zwischen den Richtlinien verschieben, nicht eine Datei überschreiben, während Clients sie herunterladen.

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 Cohorten vor breiter Aussetzung

A custom manifest field can express staged delivery:

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

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

Erweitern Sie die Kohorte nur, nachdem die Veröffentlichung ihre Beobachtungszeit überlebt hat. Die genaue Zeit sollte Ihren Nutzungsmuster entsprechen, aber die Entscheidung sollte auf Signale basieren, nicht auf einem Kalender allein. Verfolgen Sie die Ergebnisse der Update-Überprüfungen, der Download-Vollständigkeit, der Startgesundheit, der Crashs, der Renderer-Ausnahmen und der Authentifizierungserfolge.

Don’t confuse rollback with deleting an artifact. Existing clients may have cached metadata, and some may already be running the bad version. A rollback plan needs a previous signed release, a feed change, and a client behavior that can recover.

Betriebsregel: Rückkehr muss von dem im Notfall eingesetzten Ingenieur ohne Wiederaufbau der Anwendung während des Vorfalls durchführbar sein.

In der Praxis sollte das Runbook die vorherige Veröffentlichungsmanifest zurück in den betroffenen Kanal pushen, den Staging-Marker invalidieren und bestätigen, dass neue Überprüfungen auf die sichere Version auslaufen. Wenn das Problem im Renderer code und nicht im native Shell liegt, kann eine gezielte Web-Schicht-Rückkehr schneller sein. Ein Plattform wie Capgo-phasische Rollouts kann für das separate Lieferungsschicht relevant sein, aber es sollte die Grenze zwischen einer nativen Binär-rollback und einer Web-Bundle-Rollback nicht verschleiern.

Auto-Update als Sicherheitskontrolle behandeln

Ein Electron-Updater lädt ausführbares code herunter und kann es mit wenig Benutzerinteraktion installieren. Das macht den Updatepfad zu einem Sicherheitsgrenze, nicht nur ein Komfortfeature. 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 in der Elektron-Builder-Automatisierung von Sicherheitsdokumentationen.

Die Code-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. Auf macOS kombinieren Sie das Signieren mit der Notarisation und dem sicheren Laufzeitumfeld, das Ihrem Anwendungsprogramm entspricht. Auf Windows machen Sie die Zertifikatsbesitz, -erneuerung und -Zugriff auf die Build auditable. Linux benötigt eine distributionsspezifische Strategie, da Electron keinen universalen Updater bereitstellt.

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

A gezeichnete Binärdatei kann immer noch mit dem falschen Release assoziiert werden, wenn das Metadatenkanal kompromittiert oder falsch konfiguriert ist. Überlegen Sie, eine Manifestsignatur zu hinzufügen, die gegen ein öffentliches Schlüssel in der Anwendung verifiziert wird, ein Mindestzulässiges Versionsniveau festlegen und unerwartete Downgrades nur dann zulassen, wenn ein autorisierter Wiederherstellungsverlauf sie explizit erlaubt.

Der Feed verdient auch Produktionskontrollen:

• Beschränken Sie den Zugriff auf Veröffentlichungen: Berechtige CI nur auf die erforderlichen Berechtigungen, um Release-Assets zu veröffentlichen.
• Sichern Sie Signierungsschlüssel: Halten Sie Zertifikate und private Schlüssel in verwaltetem geheimen Speicher, nicht in Repository-Dateien.
• Pinnen Sie Abhängigkeiten: Locken Sie Electron, electron-builder und transitive Abhängigkeiten in CI.
• Überprüfen Sie Artefakte: Scannen Sie die generierten Pakete und vergleichen Sie sie mit der beabsichtigten Commit und Version.
• Erwarten Sie sichere Transporte: Beachten Sie ATS- und strikte HTTPS-Anforderungen für Update-Anfragen.
• Überwachung von Fehlern bei der Verifizierung: Behandeln Sie wiederholte Signatur- oder Manifestfehler als Sicherheitsereignisse und nicht als gewöhnliches Netzwerkgeräusch.

Das von Electron verwaltete Werkzeug-Ökosystem setzt sich weiterhin mit der Abdeckung von Paketen und Updatern fort, aber die Wartung entfernt nicht die Notwendigkeit für die Gefahrenanalyse. Das praktische Ziel besteht darin sicherzustellen, dass ein Angreifer, der eine Bucket, einen CDN oder einen Build-Schritt kompromittiert, immer noch nicht in der Lage ist, dass der Client einen unautorisierten Release akzeptiert. Die Signaturverifizierungsanleitung bietet wertvolle Kontextinformationen für die Gestaltung dieses zusätzlichen Verifizierungsstapels.

Das Produktionsupdate-Runbook und die Checkliste

Ein Release ist nur dann bereit, wenn ein anderer Ingenieur es unter Druck betreiben kann. Halten Sie die Checkliste in der Nähe des Bereitstellungsjobs und des Vorfällenkanals.

Vorab-Übergänge

• Versionen identifizieren: Bestätigen Sie die Paketversion, die Release-Tag, der Commit-SHA und die Änderungsliste.
• Signieren: Überprüfen Sie, dass alle Plattform-Artikel signiert sind und die Notarisation oder eine äquivalente Validierung abgeschlossen wurde.
• Manifestvertrag: Bestätigen 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 in den internen oder Beta-Feed.
• Telemetrie: Bestätige Aktualisierungsprüfungen, Download-Progress, Installationsabschluss, Startgesundheit und Fehler werden eingeliefert.

Kanarische und volle Rollout

• Kohortenkontrolle: Mit einer absichtlich kleinen internen oder Beta-Audienz beginnen.
• Gesundheitsbudget: Halten Sie die Promotion, wenn Launch-Fehler, Download-Fehler, Renderer-Ausnahmen oder Authentifizierungsfehler die genehmigten Grenzen der Team überschreiten.
• Promotionsermächtigung: Erwarten Sie eine explizite Ja- oder Nein-Entscheidung, bevor Sie die Veröffentlichung in die stabile Feed bewegen.
• Kundeneinfluss: Stellen Sie die Unterstützungsmitteilungen vor der breiten Verteilung vor, nicht nach dem ersten Vorfall.

Vorfallreaktion

Wenn das neue Binärprogramm nicht startet, die Prozessspaltung fehlschlägt oder die Update-Downloads nicht abgeschlossen werden, stoppen Sie die Promotion sofort. Setzen Sie die vorherige signierte Manifestdatei wieder her, invalidieren Sie den Staging-Marker und überprüfen Sie, ob frische Clients auf die vorherige Version zurückkehren. Überprüfen Sie dann durch Telemetrie, ob die Flotte wiederhergestellt ist, bevor Sie die Schließung kommunizieren.

Die genauen Rollback-Befehle hängen von Ihrem Anbieter ab, aber die Sequenz sollte immer dokumentiert sein: Schalten Sie den 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 bietet einen Electron-Updater für die Lieferung von signierten Web-Schichten, gezielten Kanälen, Rollout-Kontrollen und Update-Beobachtbarkeit ohne das Neubauen der nativen Hülle für jeden Renderer-Wechsel. Wenn Sie native Binärprogramme von kontrollierten JavaScript- und CSS-Lieferungen trennen möchten, besuchen Sie Capgo und es neben Ihrem bestehenden Electron-Release-Pipeline bewerten.