Capgo 업데이트 유지 방법: 가볍고 빠르다

__CAPGO_KEEP_0__의 가장 좋은 실시간 업데이트 방법은 사용자가 거의 주의하지 못하는 방법입니다.

__CAPGO_KEEP_0__의 경우 일반적으로 세 가지 것을 의미합니다.

다운로드가 작습니다.
배포가 제어됩니다.
오류가 발생한 경우에도 즉시 복구됩니다.

React Native의 'OTA를 얇게 유지'하는 조언과 Capgo의 조언은 동일합니다. 다만 Capgo은 Capacitor 팀에게 몇 가지 추가 조절 장치를 제공합니다. 델타 업데이트, 채널, 자동 롤백, 버전 대상, and optional 종료-끝-끝 암호화.

만약에 그들을 함께 사용한다면, 전송되는 데이터가 더 작아지고, 설치가 더 빠르며, 운영에 필요한 잡일이 훨씬 줄어든다.

Lean한 것이 중요함에도 MAU가 변하지 않으면서도

Capgo의 유용한 Capgo-특정 세부사항: Capgo MAU는 30일 동안 업데이트 서비스에 접촉한 월 활성 기기 수를 의미합니다.

bundle 크기를 줄이는 것은 주로 MAU 카운팅을 줄이는 trick이 아닌데, 그것이 사용자와 팀이 실제로 느끼는 부분을 개선하는 데 중요하다.

셀룰러 또는 약한 Wi-Fi 네트워크에서 더 빠른 다운로드
보다 나은 사용자 경험을 위해 직접 업데이트
실패 또는 롤백 된 릴리스에서浪費된 대역폭을 최소화합니다.
테스트 또는 스테이징 릴리스 시 더 작은 실패 범위

Lean 업데이트는 정말로 속도, 안전성, 그리고 운영 절제에 대한 것입니다.

1. 기본적으로 델타 업데이트 사용

만약에 한 가지 일만 하겠다면, 이것을 하세요.

Capgo’s 델타 업데이트 업데이트할 파일만 다운로드하여 전체 웹 번들을 다시 다운로드하는 대신, 업데이트된 버전 사이의 변경된 파일만 다운로드합니다. 이는 정기적인 OTA 성능의 가장 큰 단일 이익입니다.

bun run build
bunx @capgo/cli@latest bundle upload --channel staging --delta

QA 패스 완료 후:

bunx @capgo/cli@latest bundle upload --channel production --delta

CI가 엄격하게 유지되기를 원한다면 --delta-only 이러한 업로드를 피하기 위해 nobody가 의도치 않게 전체 번들을 업로드하는 것을 방지하세요.

bunx @capgo/cli@latest bundle upload --channel production --delta-only

만약에 --delta-only Delta 업데이트를 지원하는 프로덕션 플릿을 사용할 때만 사용하세요. 혼합된 플러그인 버전의 경우, 델타 전달을 기반으로 하는 manifest를 지원하지 않는 더 오래된 장치가 업데이트를 다운로드할 수 없습니다.

이것은 특히 directUpdate,를 사용할 때 더 중요합니다. 사용자가 업데이트가 발견된 후 앱이 다시 로드되는 시간이 보이기 때문입니다.

2. 자산을 자산처럼 다루세요. 자바스크립트 배가 아니에요

OTA 번들이 조용히 부풀어 오르는데, 그 이유는 큰 자산 때문입니다.

Some practical rules:

JavaScript에서 큰 이미지를 inline하지 말고 일반 자산 파일이면 되면 그걸 사용하십시오.
자주 바뀌는 콘텐츠는 API 또는 CDN에 저장하여 앱 배포 패키지 내에 포함되지 않도록 하십시오.
마케팅 이미지를, 온보딩 비디오, 단기 캠페인 자산 등이 매 릴리즈마다 바뀌는 경우 주의하십시오.
안정적인 자산은 안정적으로 유지하십시오. 델타 업데이트에서는 변경되지 않은 파일을 재사용하는 대신 다시 다운로드하지 않습니다.

Capgo의 속도를 유지하는 가장 쉬운 방법 중 하나입니다. 앱이 커질수록 사용자가 다운로드해야 하는 큰 양의 미디어를 강요하는 작은 UI 수정 패턴은 최악의 패턴입니다.

3. 실제 네이티브 변경에만 네이티브 릴리즈를 유지하십시오.

Capgo은 런타임에 로드되는 HTML, CSS, JavaScript, 자산을 업데이트합니다.

다음은 올바른 채널이 아닙니다.

새 네이티브 플러그인,
권한 변경,
capacitor.config.ts 변경
iOS 또는 Android 네이티브 프로젝트 상태를 수정하는 모든 것.

성능에도 중요합니다. OTA 라인에 주요 구조적 변경을 지속적으로 푸시하면, 시간이 지남에 따라 업데이트 전략이 무거워지고 위험해집니다.

2개의 릴리스 라인을 의도적으로 사용하세요.

네이티브 라인

플러그인 변경, 권한 변경 및 네이티브 구성에 사용하세요.

bun run build
bunx cap sync

그 다음 정상적인 스토어 릴리스를 배포하세요.

Capgo 라인

안전한 웹层 반복을 위해 사용하세요.

bun run build
bunx @capgo/cli@latest bundle upload --channel production --delta

최근에 많은 수명이 긴 자산을 추가한 경우, 자주 업데이트하는 네이티브 기준선을 최신화하세요. 새로운 기준선이 포함된 최신 스토어 빌드는 미래의 Capgo diff를 작게 유지합니다.

4. 채널을 사용하여 롤아웃 크기를 작게 유지하세요.

'lean' 업데이트는 단순히 메가바이트에만 의존하는 것이 아닙니다. 또한 업데이트가 좋은지 알기 전에 업데이트를 받는 장치의 수에 대해 의존합니다.

Capgo’s 채널 시스템 그것이 제어하는 가장 깨끗한 방법입니다.

staging QA를 위해
beta 초청된 테스터를 위해
production 모두에게
hotfix 긴급 복구를 위해

간단한 흐름은 다음과 같습니다:

업로드 staging.
실제 장치에서 검증합니다.
통제 채널 또는 백분율 기반 롤아웃을 통해 점진적으로 배포합니다.
건강이 떨어지면 즉시 롤백합니다.

야생에서 여러 개의 네이티브 베이스 라인を持는 앱이 있다면, 채널을 pair하세요. 버전 목표. 그들이 더 오래된 바이너리에서 불필요하거나 무겁게 패키지를 멀리하는 것을 방지합니다.

더 긴 검토 루프를 원하는 팀에게도 Capgo이 잘 작동합니다. PR 미리보기. JS-만의 변경을 테스트하기 위해 TestFlight 또는 Play 내부 빌드에 기다리지 않고 제품, QA 및 이해관계자들이 JS-만의 변경을 테스트할 수 있도록 합니다.

5. 직접 업데이트 활성화 시, 시작 시간을 최적화하세요

업데이트를 적용하는 속도에 따라 시작 경로가 얼마나 엄격해야 하는지에 따라 업데이트를 적용하는 속도가 결정됩니다.

Capgo의 업데이트 동작 Delta 업데이트와 pair하는 것을 명시적으로 추천합니다. 그게 올바른 기본 설정입니다. directUpdate 두 번째 경계는

__CAPGO_KEEP_0__ notifyAppReady().

import { CapacitorUpdater } from '@capgo/capacitor-updater'

CapacitorUpdater.notifyAppReady()

앱이 기본 10초 이내에 준비되지 않거나, __CAPGO_KEEP_0__ 설정에서 지정한 시간 이내에 준비되지 않으면, __CAPGO_KEEP_1__은 해당 번들을 유효하지 않다고 표시하고 이전에 잘 작동하던 버전으로 복원할 수 있습니다. 이 롤백 동작은 운영 환경에서 원하는 동작이지만, 시작 시간을 깨끗하게 유지해야 합니다: notifyAppReady() Call appReadyTimeout you set in your Capacitor config, Capgo can mark that bundle invalid and restore the previous good version. That rollback behavior is what you want in production, but it also means you should keep startup clean:

앱을 즉시 다시 로드할 때 앱 상태를 저장하고 복원하십시오. notifyAppReady() 네트워크가 좋지 않은 상황과 저성능 장치 시나리오를 테스트하기 전에 널리 출시하기 전에
__CAPGO_KEEP_1__의 notifyAppReady 가이드를 최근에 검토하지 않았다면, 다시 읽어보십시오.
6. 내부 업데이트 채널을 사용하여 불필요한 네이티브 리빌드 대신 사용하십시오.
6. 내부 업데이트 채널을 사용하여 불필요한 네이티브 리빌드 대신 사용하십시오.

6. 내부 업데이트 채널을 사용하여 불필요한 네이티브 리빌드 대신 사용하십시오. 6. 내부 업데이트 채널을 사용하여 불필요한 네이티브 리빌드 대신 사용하십시오. 6. 내부 업데이트 채널을 사용하여 불필요한 네이티브 리빌드 대신 사용하십시오.

6. 내부 업데이트 채널을 사용하여 불필요한 네이티브 리빌드 대신 사용하십시오.

많은 모바일 팀이 웹 전용으로明显한 변경에 대한 바이너리 빌드를 빌드하는 시간을浪費합니다.

변경이:

복사,
UI 개선,
온보딩 플로우,
가격화 화면 로직,
분석 연결,
기능 플래그,
prompt 또는 API 응답 렌더링,

그런 다음 Capgo 업데이트는 종종 더 빠른 검토 항목입니다.

이것은 더 적은 네이티브 리빌드, 더 적은 테스트 플라이트 churn, 그리고 팀에 대한 더 긴 피드백 루프로 이어집니다. 이것은 Capgo의 가장 미사용된 이점 중 하나입니다: 네이티브/웹 경계를 깨지지 않고 OTA 라인으로 리뷰 및 QA 작업을 더 많이 이동할 수 있습니다.

Capgo에 대한 우리의 가이드 개발 중인 앱 ID 하나 실무적인 관점에서 이 CLEAN을 유지하는 방법을 다룹니다.

7. lean과 secret을 분리하세요

작은 패키지와 안전한 패키지는 서로 다른 문제를 해결합니다.

채널은 승인 여부를 제어합니다. 채널 하나만으로는 패키지를 비밀로 할 수 없습니다.

강한 전달 보증이 필요하다면:

켜기 라이브 업데이트 암호화,
사용 커스텀 스토리지 또는 자체 호스팅 전달,
CI 또는 보안된 운영자 워크플로우에서만 개인 키를 유지하세요.

업데이트 크기는 무시할 수 없습니다. 단지 두 가지 측면을 모두 최적화해야 한다는 뜻입니다.

속도 향상을 위해 __CAPGO_KEEP_0__
배송 제어를 위해 암호화
배포 제어를 위해 채널
복구를 위해 롤백.

A practical “lean Capgo” workflow

기본 운영 모델이 간단하고 싶다면 사용하세요.

원본과 OTA 릴리즈 채널을 분리하세요.
JS 변경 사항을 --delta 기본적으로.
이용하여 staging 채널을 beta 기본적으로 production.
__CAPGO_KEEP_0__ 업데이트 통계 및 로그를 확인하세요. 배포 후에도, 단순히 배포 전만 확인하는 것이 아닙니다.
PR을 통해 네이티브 빌드가 필요하지 않은 경우 설치 가능한 프리뷰로 변환하세요.
가능한 경우, 자주 변경되는 큰 미디어를 번들에서 제외하세요.
네이티브 베이스 라인 업데이트를 주요 자산 증가 또는 네이티브 변경과 함께 진행하세요.
Treat notifyAppReady() 배포 엔지니어링의 일부로 롤백 동작을 처리하세요. 네이티브 설정은 간단한 문제가 아닙니다.

이 combination은 일반적인 “변경된 것만 업로드” 접근 방식보다 오래 지속되는 빠른 combination입니다.

마무리

Capgo 팀에게는 “lean and fast”는 단순히 번들 크기 문제가 아닙니다.

그것은 릴리스 디자인 문제입니다.

__CAPGO_KEEP_0__ 크기 payload를 위해 Delta 업데이트를 사용하고, 롤아웃 크기, 실패 크기, 채널을 사용하고, 실패 크기, 롤백을 사용하세요. OTA를 그렇게 생각하면, 앱, 팀, 사용자 베이스가 커져도 업데이트가 빠르게 유지됩니다.

Capgo 업데이트를 Lean하고 빠르게 유지하는 방법에서 계속하세요.

__CAPGO_KEEP_0__을 사용하여 Capgo 업데이트를 Lean하고 빠르게 유지하는 방법 를 사용하여 채널 라우팅과 단계별 롤아웃을 계획하고, 그것을 Channels 에 연결하세요. Channels 에 대한 구현 세부 정보 Channels 에 대한 구현 세부 정보 Channels에 대한 구현 세부 정보 Beta 테스트 솔루션에서 제품 워크플로우를 위한 버전 목표 솔루션 버전 목표 솔루션에서 제품 워크플로우를 위한