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

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

업데이트를 찾지 못한 사용자가 있습니다. 다운로드도 완료했지만 설치가 불가능합니다. 또 다른 사용자는 아직도 오래된 바이너리를 사용하고 인증 흐름이 깨진 상태입니다. 로그는 거의 아무것도 표시하지 않습니다. 전자 앱 자동 업데이트업데이터 API는 단일 구성 요소입니다. 실제 배포에는 플랫폼 서명, 전송 정책, 매니페스트, 호스팅, 라이프 사이클 이벤트, 관찰성, 롤아웃 제어 및 롤백 경로가 포함됩니다. 그 중 하나를 선택적으로 처리하고 일상적인 패치가 밤새 발생하는 사고가 될 수 있습니다.

내용 목록

• 2시의 업데이트 사고로 시작한 이 안내서
• 전자 업데이터 경로를 선택하는 방법
• 메인 프로세스에서 자동 업데이트 흐름을 implement하는 방법
  • 배포 대상 설정을 먼저 구성하세요
  • 라이프 사이클 이벤트를 노출하고 체크를 스케줄하세요
  • 작업을 막지 않고 렌더러에게 정보를 제공하세요
• 서명된 릴리즈와 매니페스트를 위한 CI/CD를 구성하세요
  • CI에서 서명이 명확하게 나타나도록 하세요
• 롤아웃, 채널 및 롤백 전략
  • __CAPGO_KEEP_0__
• __CAPGO_KEEP_0__
  • __CAPGO_KEEP_0__
• __CAPGO_KEEP_0__
  • __CAPGO_KEEP_0__
  • __CAPGO_KEEP_0__
  • __CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

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

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

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

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

업데이트를 자동으로 처리하는 데 필요한 운영 체제 서명은 릴리스 게이트입니다. 매니페스트는 클라이언트 계약을 정의하고, 롤아웃 채널은 노출을 제한하고, 롤백은 테스트된 경로가 아닌 비상 사태로 인한 발명이 아닙니다.Electron 업데이터 경로 선택

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

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의 Electron 업데이터 통합

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.

커스텀 서비스인 하젤, 나츠, 또는 내부 피드가 릴리즈 권한, 테넌트 타겟팅, 감사 기록, 또는 규제된 배포 규칙이 구현 비용을 정당화할 때 적합합니다. 트레이드 오프는 지속적인 소유입니다. 팀은 매니페스트 의미를 정의하고, 서명 키를 보호하고, 클라이언트 호환성을 유지하고, 실패한 다운로드, 거부된 릴리스, 롤백 동작을 테스트해야 합니다.

라이브 업데이트는 렌더러만 변경하는 경우 렌더러만 다시 빌드하지 않고도 배포할 수 있습니다. 이들은 이지리언, 네이티브 모듈, 권한, 설치 프로그램 동작이 변경되는 경우 바이너리 업데이트를 대체하지 않습니다. 이전트 업데이터를 사용하는 것이 좋습니다. 만약 커스텀 롤아웃 로직이 필요하다면. 커스텀 로직이 필요하다면 established 매니페스트와 아티팩트 convention을 따라서 다운로드 및 다이내믹 업데이트 동작을 재현하지 말고. 팀이 압박을 받을 때 관찰, 스테이지, 역전할 수 있는 신뢰할 수 있는 경로를 선택하세요.

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

배포 목표를 구성하세요.

최소한의 이지리언 빌더 구성이 다음과 같이 보일 수 있습니다.

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

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

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

호출

업데이트 체크 및 설치는 메인 프로세스가 소유해야 합니다. 렌더러는 상태를 표시할 수 있지만, 실행 가능한 업데이트가 신뢰되거나 애플리케이션이 종료될 때 결정할 수 없습니다. 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의 첫 번째 런 케이스를 포함합니다. 애플리케이션이 필요로 하는 플랫폼 특정 초기화를 완료하기 전에 업데이트를 확인하지 마십시오.

렌더러를 알리면서 작업을 막지 마십시오.

프리로드 브리지는 좁은 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(), 일반적인 창 닫기 핸들러가 설치자가 제어를 장악하지 못하게 막을 수 있으므로.

두 가지 실패는 명시적인 테스트가 필요합니다. 첫 번째는 이미 실행 중인 클라이언트가 schedule에 따라 호출해야 하며, 시작 시에만 호출하는 것이 아닙니다. 두 번째는 event가 로그와 테เล메트리에 도달해야 합니다. 앱이 보고하지 않고 먹어치우면, 앱이 재시작을 즉시 필요로 하는 강력한 이유가 없다면, checkForUpdates() on a schedule, not only at launch. Second, the 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__ 형태는 다음과 같습니다:

플랫폼에 특정한 비밀을 사용하고 서명 매체를 저장소 외부에 유지하세요. 서명 실패는 작업을 중단하고,有人 수동으로 업로드하는_unsigned fallback를 생성하지 않도록 하세요.

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

목적

공개 설정에서 공급자와 채널을 일관되게 식별해야 합니다:

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

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

이러한 검사들은 signed installation test를 대체하지 않습니다. 그러나 업로드한 바이너리가 클라이언트가 이를 발견할 수 있도록 필요한 메타데이터가 없는 경우에 발생하는 운영 오류를 잡을 수 있습니다.

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

continuous integration setup guide

릴리스, 채널, 롤백 전략

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

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

코호트 사용 전 넓은 노출

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

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

메인 프로세스는 안정적인 사용자별 버킷을 assign하고 그 버킷을 rolloutPercentage와 비교할 수 있습니다. 안정적인 assignment이 중요합니다. 사용자가 매 체크에서 적격 및 불적격 상태 사이를 이동하는 경우 불확실한 동작을 받고 지원 보고서를 해석하기 어려울 것입니다.

릴리스가 관찰 기간을 통과한 후에만 코호트를 확장하십시오. 정확한 기간은 사용 패턴에 따라 반영되어야 하지만, 결정은 시계만큼 단순하게 하지 말고 신호에 기반해야 합니다. 업데이트 체크 결과, 다운로드 완료, 런타임 건강, 충돌, 렌더러 예외, 인증 성공을 추적하십시오.

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

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

실제로, 롤백북은 이전 릴리스 매니페스트를 영향을 받는 채널로 승격시키고, 스테이징 마커를 invalidate하고, 새로운 체크가 안전한 버전으로 해결되는지 확인해야 합니다. 문제가 렌더러 code에 있지 않은 렌더러 code에 있으면, 대상화된 웹层 롤백이 더 빠를 수 있습니다. 이러한 분리된 배포 층에 대한 code phased rollouts Capgo phased rollouts 자동 업데이트 관리를 보안 제어로 다루기

전자 업데이터는 실행 가능한 __CAPGO_KEEP_0__을 다운로드하고 사용자와의 상호 작용이 적은 설치로 업데이트를 설치할 수 있습니다. 따라서 업데이트 경로가 보안 제어로 다루어질 수 있습니다.

code phased rollouts 보안 경계, 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 Electron의 공식 문서는 macOS ATS와 같은 플랫폼 제약을 설명하고 있으며, 보안 커버리지가 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에서는 인증과 함께 노타리제이션과 런타임을 강화하고 애플리케이션에 적합한 런타임을 combination하세요. Windows에서는 인증서 소유권, 갱신, 빌드 접근 권한을 감사하세요. Linux에서는 Electron이 제공하는 빌트인 universal 업데이트가 없기 때문에 distribution-specific 전략이 필요합니다.

메타데이터를 바이너리와 마찬가지로 보호하세요

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

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

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

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

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

릴리스 전 검증 단계

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

카나리 및 전체 롤아웃

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

사고 대응

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

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

Capgo은 signed web-layer 변경을 전달하는 Electron 업데이터를 제공하며, 목표 채널, 롤아웃 제어 및 업데이트 관찰성을 제공합니다. native shell을 다시 빌드하지 않고 renderer 변경에 따라 native 바이너리 릴리스와 제어된 JavaScript 및 CSS 전달을 분리하고 싶다면, 방문하세요: Capgo 그리고 기존 Electron 릴리스 PIPELINE과 함께 평가하세요.