Electron 앱 자동 업데이트: 실용적인 2026년 가이드

Electron 앱 자동 업데이트: 실용적인 2026년 가이드

업데이트를 찾지 못한 사용자가 있습니다. 업데이트를 다운로드한 사용자가 있지만 설치할 수 없습니다. 오래된 바이너리에서 인증 흐름이 깨진 사용자가 있습니다. 로그는 거의 NOTHING을 보여줍니다. 전자 앱 자동 업데이트업데이터 API는 단 하나의 컴포넌트입니다. 실제 배포도 플랫폼 서명, 전송 정책, 매니페스트, 호스팅, 라이프 사이클 이벤트, 관찰성, 롤아웃 제어, 롤백 경로 등에 의존합니다. 그 중 하나를 선택적으로 간주하고 일상적인 패치가 밤중의 사고가 될 수 있습니다.

내용목록

• 2시의 업데이트 사고로 시작한 이 가이드
• 전자 업데이터 경로를 선택하는 방법
• 메인 프로세스에서 자동 업데이트 플로우를 implement하는 방법
  • 배포 목표를 먼저 구성하세요
  • 라이프 사이클 이벤트를 노출하고 체크를 스케줄하세요
  • 작업을 막지 않고 렌더러에게 정보를 제공하세요
• 서명된 릴리즈와 매니페스트를 위한 CI/CD를 구성하세요
  • CI에서 서명이 명확하게 드러나게 하세요
• 롤아웃, 채널, 롤백 전략
  • 코호트를 먼저 노출하기 전에 넓은 노출을 사용하세요
• 자동 업데이트 관리를 보안 제어로 다루기
  • metadata를 바이너리와同様로 보호하십시오
• Electron 애플리케이션 자동 업데이트
  • 기본 버전 출시 전 검증 단계
  • Canary 및 전체 배포
  • 응급 대응

이 가이드의 시작은 2시의 업데이트 사고에서 시작되었습니다.

CI 테스트를 통과한 릴리스는 정상적으로 보였다. 금요일 늦게, 개발자가 unsigned Electron 빌드를 푸시했고, 릴리스가 완전하다고 보이도록 publish 작업이 충분한 자산을 업로드했다. 테스트 환경에서 애플리케이션이 실행되었지만, 설치된 프로덕션 빌드에서 업데이트 경로를 실행한 사람은 아무도 없었다.

2시 8분에 PagerDuty는 대기 중인 엔지니어에게 경보를 발령했습니다. 일부 배포에서 새로운 인증 흐름이 실패하여 업데이트를 받은 사용자는 로그인 완료가 불가능했습니다. 다른 사용자는 업데이터가 아티팩트를 확인하거나 설치할 수 없기 때문에 이전 버전을 유지했습니다. 일부 고객은 깨진 릴리스를 사용했고 나머지 배포는 명확한 설명이 없는 다른 버전을 실행했습니다.

5 가지 확인을 거친 후에 조사가 진행되었습니다.

1. 업데이트 피드 확인하세요. 바이너리가 존재했지만, 기대되는 메타데이터가 명확하게 클라이언트가 받을 것을 정의하지 못했다. 릴리스 PIPELINE과 설치된 클라이언트 간의 계약은 optional 업로드 세부사항이 아닌 매니페스트이다.
2. 서명 검사. 릴리스가 올바르게 서명되지 않았기 때문에 영향을 받은 플랫폼에서 검증이 실패했다. 서명은 누락되거나 유효하지 않으면 배포를 차단해야 한다.
3. 클라이언트 로그를 비교하십시오. 업데이트 오류는 중앙 전원계측에 도달하지 못했다. 애플리케이션은 이벤트를 삼키고 계속 실행했기 때문에 팀은 신뢰할 수 있는 증거를 얻지 못했다.
4. 롤아웃 제어를 확인하십시오. 내부 채널이나 스테이징된 계층이 존재하지 않았다. 모든 자격이 있는 클라이언트가 동일한 피드만 사용했기 때문에 실패가 퍼졌으며 제한점이 없었다.
5. 롤백을 찾으십시오. 팀은 이전 버전이나 클라이언트가 깨진 릴리스에서 멀어지도록 지시할 수 있는 테스트된 절차가 없었다.

Electron의 공식 문서는 플랫폼의 한계를 명확하게 설명한다. Linux는 내장된 자동 업데이트 지원이 없으며macOS 업데이트 요청은 애플리케이션 전송 보안 요구 사항문서에는 신뢰할 수 있는 macOS 업데이트 및 릴리스 확인을 위해 서명이 필수적임을 설명합니다. 전자 애플리케이션 업데이터 문서 API 제약 조건을 정의하며 릴리스 시스템은 주변 운영 제어를 강제해야 합니다.

사후 분석 교훈: 설명할 수 없는 업데이터는 미리 설치된 미리미리 모니터링이 없는 원격 설치 시도입니다.

비용은 엔지니어링 시간만큼 더 커졌습니다. 고객들은 데스크톱 클라이언트에 대한 신뢰를 잃었고, 지원 팀은 불일치하는 동작을 설명해야 했으며, 팀은 다음 일요일에 재건된 릴리스 프로세스를 다시 구축해야 했습니다.

자동 업데이트 관리를 위한 올바른 Electron 업데이터 경로 선택 2시가 넘은 업데이터 선택은 운영 문제가 됩니다. 네이티브 바이너리 업데이트에는 서명, 매니페스트, 설치 프로그램, 롤백이 포함됩니다. 렌더러 전용 자바스크립트 또는 CSS 변경은 다른 경로를 따릅니다. 호스팅 제약 조건도 중요합니다: 작은 __CAPGO_KEEP_0__ 호스팅 프로젝트는 기업 배포 서비스와 같은 릴리스 제어를 필요로 하지 않습니다.자동 업데이트 관리를 위한 올바른 Electron 업데이터 경로 선택

업데이터 경로를 선택할 때는 운영 체제를 고려해야 합니다.

At 2 a.m., the wrong updater choice becomes an operational problem. A native binary update must handle signing, manifests, installers, and rollback. A renderer-only JavaScript or CSS change follows a different path. Hosting constraints also matter: a small GitHub-hosted project does not need the same release controls as an enterprise distribution service.

전자 애플리케이션 업데이트를 자동화하는 방법 electron-updater electron-updater Electron updater integration for Capgo Capacitor

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.

Hazel, Nuts, 또는 내부 피드와 같은 사용자 정의 서비스가 릴리스 인증, 테넌트 목표, 감사 기록, 또는 규제된 배포 규칙이 구현 비용을 정당화할 때 적합합니다. ongoing ownership의 트레이드 오프는 팀이 매니페스트 의미를 정의하고, 서명 키를 보호하고, 클라이언트 호환성을 유지하고, 실패한 다운로드, 거부된 릴리스, 롤백 동작을 테스트해야 합니다.

라이브 업데이트는 렌더러만 변경하는 업데이트를 보내고 네이티브 셸을 다시 빌드하지 않습니다. 이들은 Electron, 네이티브 모듈, 권한, 설치 프로그램 동작이 변경될 때 바이너리 업데이트를 대체하지 않습니다. electron-updater를 사용하는 것이 좋습니다. 사용자 정의 롤아웃 논리가 필요하다면. 사용자 정의 논리가 필요하다면, 다운로드 및 차등 업데이트 동작을 재현하는 대신 established 매니페스트 및 아티팩트 규약을 기준으로 빌드하세요. 팀이 압박을 받을 때 관찰, 스테이지, 역전할 수 있는 신뢰할 수 있는 경로를 선택하세요.

메인 프로세스에서 Auto-Update Flow Implement

메인 프로세스가 업데이트를 확인하고 설치해야 합니다. 렌더러는 상태를 표시할 수 있지만, 실행 가능한 업데이트가 신뢰되거나 애플리케이션이 종료될 때 결정할 수 없습니다.

배포 대상 설정을 먼저 구성하세요

최소한의 electron-builder 구성이 다음처럼 보일 수 있습니다.

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

베타 및 스테이블 피드를 분리하세요. 채널은 UI 레이블이 아닌 릴리스 정책입니다. 각 채널은 올바른 서명된 아티팩트 및 매니페스트로 해결되어야 합니다.

체크를 스케줄하고 라이프 사이클 이벤트를 노출하세요

호출 checkForUpdates() 시작 중인 동안만 일반적인 생산 오류입니다. 사용자는 애플리케이션을 열어두고 days가 될 수 있으므로 메인 프로세스는 제어 된 간격과 재시도 전략이 오프라인 작동을 존중해야 합니다.

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

정확한 업데이트 이벤트 동작은 플랫폼과 패키징 설정에 따라 다르므로 개발 모드가 아닌 설치된 아티팩트에서 테스트하는 것이 좋습니다. Electron의 문서는 Windows에서 시작 시간에 대한 문제를 언급하며, Squirrel의 첫 번째 런 케이스도 포함합니다. 애플리케이션이 필요로 하는 플랫폼 특정 초기화가 완료되기 전에 업데이트를 확인하는 것을 피해야 합니다.

렌더러를 알리면서 작업을 막지 않도록 합니다.

프리로드 브리지는 narrow한 API를 노출해야 합니다:

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

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

렌더러 쪽 진행 표시줄은 의도적으로 단순하게 유지할 수 있습니다:

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

생산 환경에서 사용자 동의 없이 설치를 막아야 합니다. 즉시 재시작해야 하는 강력한 이유가 없다면 플래그를 설정하기 전에 isQuitting flag를 설정하기 전에 quitAndInstall()https://raw.githubusercontent.com/electron-userland/electron-builder/master/docs/electron-builder-autoupdate.png에서 스크린샷을 참조하세요.

schedule에 호출해야 하며, 시작 시에만 호출하는 것이 아닙니다. 두 번째로, checkForUpdates() 이벤트는 로그와 테เล메트리에도 도달해야 합니다. 앱이 이벤트를 보고하지 않고 삼키는 경우, error event must reach logs and telemetry. If the app swallows it without reporting, your 애플리케이션 문제 해결 워크플로우 증거 대신 추측으로 시작합니다.

Signed Releases 및 Manifests에 대한 CI/CD 구성

릴리스 PIPELINE은 사용자가 설치하는 것의 참조가 되는 소스입니다. 개발자의 한 명의 머신에서 작동하는 로컬 빌드가 릴리스 바이너리, 매니페스트, 서명, 채널이 모두 동일한 릴리스를 설명하는지 증명하지 않습니다.

Electron-builder의 릴리스 모델은 릴리스 메타데이터와 업데이트가 목표를 함께 전송하는 것을 기대합니다. 많은 구성에서, 이는 플랫폼별 패키지와 블록맵 파일과 함께 Windows와 macOS에 대한 artifact를 의미합니다. 매니페스트가 누락된 경우 완벽한 유효한 바이너리는 클라이언트에 보이지 않습니다. latest.yml CI에서 서명하는 것을 명확하게 하세요 latest-mac.yml Actions 패턴이 단순화된 __CAPGO_KEEP_0__ 형태는 다음과 같습니다:

플랫폼별 비밀을 사용하고 서명 매체를 저장소 외부에 유지하세요. 서명 실패는 작업을 중단해야 하며,有人 수동으로 업로드하는 서명되지 않은 대체를 생성하지 않아야 합니다.

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

목적

__CAPGO_KEEP_0__ 발행 설정은 공급자와 채널을 일관되게 식별해야 합니다:

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

__CAPGO_KEEP_0__ 배포 전에 패키지 버전, 태그, 커밋 SHA, 스모크 테스트 결과에 따라 작업을 게이트링합니다. 배포 후에는 피드에 기대되는 매니페스트가 포함되어 있는지 확인하고 매니페스트가 그 작업으로부터 생성된 정확한 아티팩트를 참조하는지 확인합니다. __CAPGO_KEEP_0__ 지속적인 통합 설정 가이드 __CAPGO_KEEP_0__ formalizing those checks를 formalize할 때 유용하며 pipeline orchestration을 비교하는 팀도 Jenkins와 Ansible를 함께 사용할 때를 이해하는 데 도움이 됩니다. __CAPGO_KEEP_0__ 일반적으로 불완전한 릴리스를 노출하는 명령어는 의도적으로 재미없습니다:.

__CAPGO_KEEP_0__ 그 검사는 서명된 설치 테스트를 대체하지 않습니다. 그 검사는 업로드한 바이너리가 클라이언트가 그것을 발견하기 위해 필요한 메타데이터가 없는 경우에 발생하는 운영 오류를 잡을 수 있습니다.

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

__CAPGO_KEEP_0__

릴리스, 채널, 롤백 전략

릴리스 피드는 배포 목적지보다 다운로드 폴더처럼 행동해야 합니다. 내부, beta, 그리고 최신 채널을 분리하고, 각 채널은 자신의 매니페스트와 서명된 아티팩트 세트로 지원되어야 합니다. 승격은 테스트된 릴리스를 정책 사이에 이동시키고, 클라이언트가 다운로드 중인 파일을 덮어쓰지 않도록 해야 합니다.

채널 분리는 실수로 테스트 빌드를 보호합니다. 업데이터는 클라이언트가 내부 그룹, 베타 대상자, 또는 안정적인 인구에 속하는지 평가하기 전에 그에 속하는지 여부를 알 수 있어야 합니다.

코호트 사용 전 널리 노출되지 않도록

사용자 지정 매니페스트 필드는 단계적 배포를 표현할 수 있습니다:

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

메인 프로세스는 안정적인 사용자별 버킷을 assign하고, 그 버킷을 rolloutPercentage안정적인 assignment이 중요합니다. 사용자가 매 체크에서 합격 및 불합격 상태를 바꾸면, 불확실한 동작을 받고, 지원 보고서를 해석하기 어려워질 것입니다.

릴리스가 관찰 기간을 통과한 후에만 코호트를 확장하십시오. 정확한 기간은 사용 패턴에 따라 반영되어야 하지만, 결정은 신호에 따라야 하며, 단순히 달력에만 의존해서는 안 됩니다. 업데이트 체크 결과, 다운로드 완료, 런칭 건강, 충돌, 렌더러 예외, 및 인증 성공을 추적하십시오.

롤백과 아티팩트 삭제를 혼동하지 마십시오. 기존 클라이언트는 캐시된 메타데이터를 가지고 있으며 일부는 이미 문제가 있는 버전을 실행하고 있을 수 있습니다. 롤백 계획에는 이전에 서명된 릴리스, 피드 변경, 클라이언트가 회복할 수 있는 동작이 필요합니다.

운영 규칙: 롤백은 재빌드 없이 인콜 엔지니어가 실행할 수 있어야 합니다.

실제로, 런북은 이전 릴리스 매니페스트를 영향을 받는 채널로 승격시키고 스테이징 마커를 invalidate하고 새로운 체크가 안전한 버전으로 해결되는 것을 확인해야 합니다. 문제가 렌더러 code rather than native shell에 있다면, 대상화된 웹 레이어 롤백이 더 빠를 수 있습니다. 플랫폼으로 Capgo phased rollouts 은 그 별도의 배포 층위에 관련이 있을 수 있지만, native 바이너리 롤백과 웹-배ंडल 롤백 사이의 경계를 가려서는 안됩니다.

자동 업데이트 관리를 보안 제어로 다루기

전자 업데이터는 실행 가능한 code을 다운로드하고 사용자와의 상호 작용이 적은 설치로 업데이트를 설치할 수 있습니다. 따라서 업데이트 경로를 보안 제어로 다루는 것이 중요합니다. 보안 경계, not merely a convenience feature. Electron’s official documentation describes platform constraints such as macOS ATS, and security coverage has documented a 2022 scenario in which attackers controlling update infrastructure could serve malicious packages that still passed code-signing checks, as discussed in the macOS ATS와 같은 플랫폼 제약 조건에 대한 Electron의 공식 문서가 설명하고 있으며, 공격자가 업데이트아키텍처를 통제할 수 있는 2022년 시나리오에 대한 보안 커버가 문서화되어 있습니다. 공격자가 __CAPGO_KEEP_0__-인증서를 통과하는 악성 패키지를 제공할 수 있었던 것입니다..

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.

__CAPGO_KEEP_0__ 인증서가 기초적이지만, 신뢰 모델의 전부는 아닙니다. 모든 릴리즈를 인증하고, CI에서 인증서와 식별자를 검증하고, 문서화된 키 회전 절차를 유지하세요. macOS에서는 인증서와 hardened 런타임을 combination하여 사용하세요. Windows에서는 인증서 소유권, 갱신, 빌드 접근 권한을 감사할 수 있도록 하세요. Linux에서는 Electron이 제공하는 UNIVERSAL 업데이트가 없기 때문에 distribution-specific 전략이 필요합니다.

메타데이터도 바이너리와 같이 보호하세요

인증된 바이너리가 메타데이터 채널이 취약하거나 미설정된 경우 잘못된 릴리즈와 연관될 수 있습니다. 공개 키를 애플리케이션에 임베디드한 후에 manifest 인증서를 검증하고, 최소 허용된 버전을 강제하고, 권한이 있는 복구 경로가 명시적으로 허용하지 않는 이상 예상치 못한 다운그레이드를 거부하세요.

• 피드도 프로덕션 제어를 필요로합니다: 게시권한을 제한하세요:
• CI에 릴리즈 자산을 게시할 수 있는 권한만 부여하세요. 인증서를 보호하세요:
• 의존성 고정: CI에서 Electron, electron-builder 및 전이적 의존성을 고정합니다.
• 아티팩트 검토: 생성된 패키지를 검사하고 의도한 커밋 및 버전과 비교합니다.
• 안전한 전송 요구: 업데이트 요청에 대해 ATS 및 엄격한 HTTPS 요구 사항을 따릅니다.
• 인증 확인 실패 모니터링: 반복적인 서명 또는 매니페스트 실패를 보안 이벤트로 대신 일반 네트워크 잡음으로 처리합니다.

Electron의 유지 보수 도구 생태계는 계속해서 패키징 및 업데이터 커버리지를 추가하고 있지만 유지 보수는 위협 모델링의 필요성을 제거하지는 않습니다. 실제 목표는 공격자가 버킷, CDN 또는 빌드 단계를 compromis하는 경우에도 클라이언트가 비인가된 릴리즈를 수락하지 못하도록 하기 위함입니다. 서명 확인 지침 의용적인 추가 확인層을 설계하는 데 유용한 맥락을 제공합니다.

제작 업데이트 실행 매뉴얼 및 체크리스트

릴리스가 준비되려면 다른 엔지니어가 압박하에 운영할 수 있어야 합니다. 체크리스트는 배포 작업과 사고 채널 근처에 유지하세요.

릴리스 전 검증 단계

• 버전 식별: 패키지 버전, 릴리스 태그, 커밋 SHA, 변경 로그가 일치하는지 확인하세요.
• 서명: 모든 플랫폼 아티팩트가 서명되어 있고, 인증 또는 동등한 검증이 완료되었는지 확인하세요.
• 매니페스트 계약: 확인 latest.yml, latest-mac.yml, 해시, 경로, 블록맵이 업로드된 아티팩트와 일치하는지 확인하세요.
• 채널 안전: 내부 또는 베타 피드에 먼저 배포한 후 릴리스 채널을 승격하세요.
• 측정 데이터: 업데이트 확인, 다운로드 진행, 설치 완료, 런칭 건강, 오류가 도착하는지 확인합니다.

카나리 및 전체 롤아웃

• 집단 제어: 내부 또는 베타 사용자로 시작하여 작은 내부 또는 베타 사용자로 시작합니다.
• 건강 지출: 런칭 실패, 업데이트 다운로드 실패, 렌더러 예외, 인증 실패가 팀 승인한 한도 초과하는 경우 프로모션을 보류합니다.
• 프로모션 승인: 릴리스를 안정적인 피드로 이동하기 전에 명시적인 '진행' 또는 '중단' 결정이 필요합니다.
• 고객 영향: 넓은 배포 전에 지원 메시지를 준비하세요, 첫 번째 사고 이후로 하지 마세요.

사고 대응

새로운 바이너리가 실행되지 않으면, 프로세스 스포우닝이 중단되거나 업데이트가 다운로드되지 않으면, 즉시 프로모션을 중단하세요. 이전에 서명한 매니페스트를 복원하고 스테이징 마커를 invalidate하고 새 클라이언트가 이전 버전으로 리졸브되는지 확인하세요. 그런 다음 수동으로 종료된 클라우드의 회복을 확인하기 위해 수동으로 종료된 클라우드의 회복을 확인하기 전에 수동으로 종료된 클라우드의 회복을 확인하세요.

제공 업체에 따라 정확한 롤백 명령은 달라지지만, 시퀀스는 항상 문서화되어야 합니다: 채널 매니페스트를 이전 버전으로 전환하고 스테이징 태그를 invalidate하고 회복이 필요하면 강제 업데이트 마커를 푸시하고 실제로 다운그레이드 경로를 라이브 테스트 모니터링을 통해 확인하세요.. 테스트되지 않은 롤백은 단지 희망입니다.

Capgo은 서명된 웹 레이어 변경을 전달하는 Electron 업데이터를 제공하며, 목표 채널, 롤아웃 제어 및 업데이트 관찰성을 제공합니다. native shell을 다시 빌드하지 않고 renderer 변경에 대해 native binary release와 제어된 JavaScript 및 CSS 전달을 분리하고 싶다면, Capgo 을 방문하세요.