Capgo에서 Live Update 채널을 관리하고 설정하는 방법을 알아보세요. 이를 통해 앱 업데이트를 위한 JS 번들 빌드를 특정 장치로 지시하여 앱 업데이트를 원활하게 할 수 있습니다.

채널

Live Update 채널은 특정 JS 번들 빌드에 대한 링크를 제공합니다. 이 빌드는 앱을 실행하는 모든 장치에 업데이트를 공유합니다. Live Updates __CAPGO_KEEP_1__를 앱에 설치하면 __CAPGO_KEEP_0__에 구성된 모든 네이티브 바이너리는 앱을 실행할 때 업데이트가 있는지 확인합니다. 채널이 가리키는 빌드는 언제든지 변경할 수 있고 이전 빌드로 롤백할 수도 있습니다. install the Capgo Live Updates SDK __CAPGO_KEEP_0__

When a device checks for an update, Capgo decides which channel to use in this strict order (highest priority first):

  1. – 특정 장치 ID를 채널에 매핑하여 강제로 지정합니다. 긴급한 디버깅이나 단일 실제 사용자와 제어된 테스트에 사용합니다. 이 항목은 항상 우선합니다. __CAPGO_KEEP_0__은 마지막 override 쓰기 후 90일 후에 매핑을 삭제합니다. 자세한 내용은 콘솔 및 Capgo override는 90일 후에 만료됩니다 Cloud override (per-device) via 대시보드 또는 API.
  2. – 대시보드 또는 API에서 장치의 채널을 변경하여 생성됩니다. QA 사용자 간의 기능/PR 채널 또는 사용자 문제를 재현하는 데 사용합니다. 바이너리 재설치를 통해 삭제되지 않습니다. 장치 override를 삭제하면 삭제됩니다. 동일한 90일의 보존 기간이 적용됩니다. – Created when you change the device’s channel in the dashboard or via API. Use for QA users switching between feature / PR channels or to reproduce a user issue. Reinstalling the binary does not clear it; deleting the device override does. The same 90-day retention applies.
  3. 플러그인 setChannel() 지역 채널 – 앱이 호출할 때 생성되며, 백엔드가 대상 채널이 자체 할당을 허용하는지 확인합니다. 선택한 채널은 해당 기기에서 지역 저장되고 즉시 적용되며, 기기 오버라이드 UI에서 표시되지 않습니다. setChannel() setChannel()을 사용한 즉시 채널switching
  1. Capacitor config defaultChannel – __CAPGO_KEEP_0__에 존재하고, 강제/override/local 채널이 없다면 앱은 이 채널에서 시작합니다 (예: ). 테스트 플라이트 / 내부 빌드에 사용하여 테스터가 자동으로 프리 리리즈 채널에 도착하도록 합니다. 프로덕션 빌드는 일반적으로 이 설정을 비워둡니다. 클라우드 기본 채널 (주요 경로 ~99%의 사용자) capacitor.config.* – 대시보드에서 기본 채널을 표시하면 모든 일반 사용자 (강제, 대시보드/ __CAPGO_KEEP_0__ override, 플러그인 로컬 채널, 구성 기본 채널이 없는 경우)가 이 채널에 연결됩니다. 변경하면 즉시 배포하거나 되돌릴 수 있습니다. 새로운 바이너리가 필요하지 않습니다. 플랫폼별 기본값 (예: iOS 전용, Android 전용, Electron 전용)을 설정한 경우 각 기기는 해당 플랫폼에 맞는 기본값으로 연결됩니다. 클라우드 기본 채널을 비워두는 것은 허용되며, 이 경우 기기는 1-4 단계를 따라야 업데이트 받을 수 있습니다. beta, qa, pr-123권장 방법:
  2. 1-4 단계를 예외/테스트層으로 간주하세요. 클라우드 기본 채널을 설정하면 실제 사용자가 이 채널로 흐를 수 있도록 하세요. 기본 채널을 설정하지 않는 경우 사용자가 어떻게 연결되는지 명확하게 하세요 (일반적으로 __CAPGO_KEEP_0__를 통해). API

__CAPGO_KEEP_0__

  • __CAPGO_KEEP_0__ defaultChannel 설정 또는 장치별 오버라이드에서 사용합니다.
  • 테스터에게 명시적으로 배포하는 바이너리에서만 구성합니다. defaultChannel 생산 로직을 중앙에서 관리하기 위해 대시보드에서 설정하지 않으면 유지합니다.
  • 생산에서 적극적으로 사용하지 마세요. QA 또는 특정한 디버깅 목적으로만 사용하세요. setChannel() 플랫폼(iOS/Android/Electron)에서 채널이 비활성화되어 선택될 경우, 선택 프로세스는 해당 채널을 건너뛰고 목록을 계속 진행합니다.

요약: 강제 > 대시보드/Override > 플러그인

Summary: Force > Dashboard/API Override > Plugin setChannel() > Cloud 기본값. defaultChannel 콘솔 및 대시보드 오버라이드가 90일 후에 만료됩니다.

Console and API overrides expire after 90 days

Section titled “Console and API overrides expire after 90 days”

Forced mappings and Dashboard or Public API channel overrides are stored as per-device assignments in Capgo. A cleanup job deletes those assignments 90일 동안 마지막 override 쓰기 후. 업데이트 확인은 그 시계를 다시 초기화하지 않습니다. 오버라이드 다시 쓰기(또는 삭제)만 timestamp를 변경합니다.

This is not the same as device inventory retention. Inventory는 90일 동안 Capgo에 연결하지 않은 장치가 삭제됩니다. Override cleanup은 장치가 활성 상태일지라도 mapping을 삭제합니다.

For an assignment that is not removed by this cleanup:

  • Set defaultChannel in capacitor.config.* (재설치 시 유지; 이후 변경을 위해 새로운 네이티브 바이너리가 필요합니다).
  • Call setChannel() context setChannel() HTML text fragment from a longer Capgo UI string (parent key `appflow_migration_step2`). Page/area: Appflow comparison / migration marketing copy. Role: Website copy sentence. Seen in: page ionic-appflow.astro. Preserve Capgo product/brand and developer terms exactly. Message key `appflow_migration_step2` (Appflow Migration Step2).

채널 기기 API tab과 기기 Override UI에서만 콘솔 및 Public assignments만 표시합니다. 그들은 채널에 있는 모든 기기를 표시하지 않으며, 그들은 지역 API assignments도 표시하지 않습니다. setChannel() __CAPGO_KEEP_0__ 채널 기기 탭에 보이기 위한 Override 보관소 팝오버: 콘솔 오버라이드는 90일 후에 만료됩니다.

Capgo 채널 기기 탭에 보이기 위한 Override 보관소 알림.
기본 채널 동작

단일 기본값 (가장 일반적인 경우) defaultChannel in the Capacitor config will receive updates. When you do choose to mark defaults, keep these patterns in mind:

  • 플랫폼별 기본값 – 플랫폼별 채널을 나누면 (예를 들어, iOS만 활성화, Android만 활성화, Electron만 활성화), 각 플랫폼의 기본값으로 표시합니다. ios-production iOS 기기는 iOS 기본값으로, Android 기기는 Android 기본값으로, Electron 앱은 Electron 기본값으로 이동합니다. android-production 클라우드 기본값과 electron-production 두 채널은 동일한 결정 계층을 차지합니다.

클라우드 기본값을 설정하면 __CAPGO_KEEP_0__ 구성에서 값을 중복해서 입력할 필요가 없습니다. defaultChannel 생산 빌드에서는 빈칸으로 남겨두세요. capacitor.config.* both occupy the same decision layer. If you set a cloud default, you don’t need to duplicate the value in your Capacitor config—leave defaultChannel 빈칸을 예약하세요. defaultChannel 비트를 배포할 때 비프로덕션 채널로 시작하도록 하려면

빈칸을 예약하세요. 클라우드 기본값을 변경할 수 있습니다. 채널을 열고, Manage in App 설정을 열어which takes you to 앱 정보. 기본 설정은 더 이상 채널 페이지에서 토글이 아닙니다. 채널을 바꿔서 새로운 장치들은 즉시 새로운 라우팅을 따르며 기존 장치들은 다음에 체크인할 때 정상적인 우선순위 규칙을 따릅니다.

온보딩 중에 첫 번째 채널을 생성합니다(대부분의 팀은 '생산'이라고 이름짓습니다). 그러나 아무것도 잠금 해제되지 않습니다. 채널 이름을 변경하거나 삭제할 수 있습니다. 추가 채널을 설정하려면:

  1. Capgo 대시보드의 '채널' 섹션으로 이동하세요
  2. 새 채널 버튼을 클릭하세요
  3. 채널 이름을 입력하고 '생성' 버튼을 클릭하세요

채널 이름은 마음대로 지정할 수 있습니다. 일반적인 전략은 개발 단계와 채널 이름을 일치시키는 것입니다. 예를 들어:

  • Development - 로컬 장치나 에뮬레이터에서 라이브 업데이트 테스트
  • QA - QA 팀이 더 넓은 릴리스 전에 업데이트 확인
  • Staging - 프로덕션 환경과 유사한 환경에서 최종 테스트를 위해
  • Production - 사용자가 앱 스토어에서 앱을 받는 버전의 앱

앱에서 채널을 구성하는 방법

앱에서 채널을 구성하는 방법

채널을 생성한 후, 앱을 채널에 맞게 구성해야 합니다. 이 예에서는 채널을 사용합니다. Development 채널.

파일을 열어보세요. capacitor.config.ts (또는 capacitor.config.json) 파일을 열어보세요. plugins 섹션 하위에, 옵션적으로 defaultChannel 채널을 테스트 빌드 생산 빌드의 경우 Cloud Default를 사용하도록 하며, Cloud Default를 명시적으로 재정의하지 않는 한 장치가 Cloud Default를 사용하도록 하세요.

import { CapacitorConfig } from '@capacitor/cli';
const config: CapacitorConfig = {
plugins: {
CapacitorUpdater: {
// For a QA/TestFlight build – testers start on the Development channel automatically.
defaultChannel: 'Development',
// Production builds usually omit this so users attach to the Cloud Default channel.
},
},
};

다음으로 웹 앱을 빌드하고 npx cap sync 업데이트된 config 파일을 iOS, Android, Electron 프로젝트에 복사하세요. 이 동기화 단계를 건너뛰면, 이전에 구성된 채널을 사용하는 native 프로젝트가 계속 사용됩니다.

채널은 업데이트를 받을 수 있는 사람과 업데이트를 전달하는 방법을 제어하는 여러 옵션을 가지고 있습니다. 가장 중요한 것은 아래에 나열되어 있습니다. 이 옵션은 웹 앱, CLI, 또는 Public API에서 구성할 수 있습니다.

  • 기본 채널: 새로운 장치가 연결될 때 채널 또는 플랫폼에 특정한 채널을 선택할 수 있습니다. 콘솔에서는 App Information(앱 설정 관리 채널 페이지에서 확인할 수 있습니다. 기본 채널 동작을 참조하세요.
  • 플랫폼 필터: iOS, Android또는 Electron 장치당 채널별로
  • 자동 다운그레이드 비활성화: 장치의 네이티브 앱 버전이 채널의 배포본보다 새로운 경우 업데이트를 보내지 않습니다. (예: 장치 버전 1.2.3, 채널 버전 1.2.2).
  • 개발 빌드 허용: 개발 빌드에 업데이트를 허용합니다. (테스트에 유용합니다.) CLI: --dev / --no-dev.
  • Allow production builds: Permit updates to production (store) builds. Leave this on for channels that serve real users. CLI: --prod / --no-prod.
  • Allow emulator devices: Permit updates to emulators/simulators (useful for testing). CLI: --emulator / --no-emulator.
  • Allow physical devices: Permit updates to real phones and tablets. Leave this on for production channels. CLI: --device / --no-device.
  • 장치 자체 할당 허용: 앱이 런타임에 이 채널로 switch할 수 있도록 허용합니다. 이 옵션을 비활성화하면 setChannelwill fail for this channel. setChannel will fail for this channel. CLI: --self-assign / --no-self-assign.
  • 업데이트 패키지all, zip, delta, zip_from_builtin, delta_from_builtin를 참조하세요. 이 모드가 유용한 경우는 각각의 모드에 대한 설명을 참조하세요. 진보적 롤아웃 Progressive rollouts

Progressive rollouts

Progressive rollouts

A 채널은 안정적인 패키지를 유지하면서 스틱이 장치 그룹에 대한 별도의 롤아웃 대상으로 점진적으로 노출할 수 있습니다. 모든 사용자에게 채널을 전환하지 않고도 일시 중단, 재개, 승격, 롤백 및 자동 실패 응답을 구성할 수 있습니다. 자세히 보기 진보적 롤아웃 배송 모델, 대시보드 워크플로우, API field 및 CLI 명령에 대한

자동 업데이트 전략 비활성화

자동 업데이트 전략 비활성화

이 옵션을 사용하여 채널이 자동으로 전달할 업데이트의 종류를 제한할 수 있습니다. 옵션:

  • major: 장치의 원래 버전보다 높은 메이저 버전을 가진 대상 패키지를 차단합니다. 예시:version_build차단됩니다; 1.2.3 -> 2.0.0 허용됩니다. 1.2.3 -> 1.9.0 minor: 대상 패키지의 메이저 또는 미니 버전이 에서 다르면 차단합니다. 예시:
  • 차단됩니다; version_build차단됩니다; 1.2.3 -> 1.3.0 차단되었습니다; 1.2.3 -> 1.2.4 허용됩니다.
  • patch: 가장 엄격한 모드입니다. 메이저, 마이너, 패치 번호의 변경은 모두 차단되며, 접미사 변경만 허용됩니다. 예시: MAJOR.MINOR.PATCH 변경되지 않습니다. 예시: 1.0.0-beta.1 -> 1.0.0-beta.2 허용됩니다. 1.0.0+build.1 -> 1.0.0+build.2 허용됩니다. 1.0.0 -> 1.0.1 차단됩니다.
  • 메타데이터: 각 번들을 위한 최소 업데이트 버전 메타데이터가 필요합니다. CLI을 사용하여 구성할 수 있습니다. --min-update-version 또는 --auto-min-update-version없음: __CAPGO_KEEP_0__에 따라
  • 호환성 semver.

이 전략은 채널의 목표 번들을 native baseline과 비교합니다. native baseline은 __CAPGO_KEEP_0__으로 전송되는 반면 version_build, 현재 다운로드 된 번들이 __CAPGO_KEEP_0__으로 전송되는 것과는 다릅니다. version_name.

Disable updates strategy에 대한 자세한 내용과 예제는 /docs/cli/commands/#disable-updates-strategy에서 확인할 수 있습니다.

CLI (예제). 채널이 이미 존재해야 하며 (CLI으로 생성되지 않음):channel set 터미널 창

클립보드에 복사
# Block major updates on the Production channel
npx @capgo/cli@latest channel set production com.example.app \
--disable-auto-update major
# Allow devices to self-assign to the Beta channel
npx @capgo/cli@latest channel set beta com.example.app --self-assign
# Production channel: store builds on real devices, no emulators
npx @capgo/cli@latest channel set production com.example.app --prod --device --no-emulator

QA/Debug 메뉴 setChannel() 테스터가 채널을 전환할 수 있는 경우

  • 채널 전환
  • Beta 프로그램 옵인 흐름
  • 기능 플래그 구현
  • A/B 테스트 시나리오
import { CapacitorUpdater } from '@capgo/capacitor-updater';
// Switch to the beta channel
await CapacitorUpdater.setChannel({ channel: 'beta' });
// Optionally trigger an immediate update check after switching
await CapacitorUpdater.setChannel({
channel: 'beta',
triggerAutoUpdate: true
});

To deploy a live update, you need to upload a new JS bundle build and assign it to a channel. You can do this in one step with the Capgo CLI:

복사
npx @capgo/cli@latest bundle upload --channel=Development

__CAPGO_KEEP_0__ __CAPGO_KEEP_1__ Development 채널. 그 채널에 연결된 앱은 다음에 업데이트를 확인할 때 업데이트를 받습니다.

또한 Capgo의 "Bundle" 섹션에서 빌드를 채널에 할당할 수 있습니다. 빌드 옆의 메뉴 아이콘을 클릭하고 "채널 Assign"을 선택하여 빌드에 채널을 할당하세요.

Bundle 버전 및 채널

Bundle 버전 및 채널 섹션

Capgo의 빌드는 앱에 전역적이지만, 채널에 특정되지 않습니다. 동일한 빌드는 여러 채널에 할당될 수 있습니다.

버전을 관리할 때, __CAPGO_KEEP_0__의 Semver Tester를 사용하여 의미 있는 버전을 사용하고, 채널에 특정된 빌드에 대해 prerelease 식별자를 사용하는 것을 추천합니다. semantic versioning with Capgo’s Semver Tester CI에서, 로컬 버전이 업로드된 경우, (optionally, 또는 )를 사용하여 __CAPGO_KEEP_0__가 채널의 연결된 빌드에서 버전을 올려 Free 이름을 찾을 때까지 버전을 올립니다. 1.2.3-beta.1.

In CI, if the local version was already uploaded, use npx @capgo/cli@latest bundle upload --auto-bump (optionally major, minor, patch/fix, metadata, or ai) so the CLI bumps from the channel’s linked bundle until a free name is found. With aiWorkers AI는 지역 vs 이전 delta 매니페스트에서 수준을 추론합니다 (이전 버전이 없으면 patch Capgo 버전이 없으면). Capgo 버전과 combination할 수 없습니다. --bundleCI/CD Integration __CAPGO_KEEP_0__ 참조 이 접근 방식에는 여러 이점이 있습니다: CLI reference.

__CAPGO_KEEP_0__는

  • 버전 번호를 여러 채널에서 재사용할 수 있으므로 혼란을 줄입니다. 1.2.3-beta.1 역할백 경로를 명확하게 활성화합니다. __CAPGO_KEEP_0__에서 역할백이 필요하면 1.2.3.
  • 역할백 경로를 명확하게 활성화합니다.
  • __CAPGO_KEEP_0__에서 역할백이 필요하면 1.2.3역할백 경로를 명확하게 활성화합니다. 1.2.2 이것은 이전에 안정적인 릴리스입니다.

다음과 같은 채널 설정과 버전을 맞추는 방법에 대한 예시입니다.

  • Development 채널: 1.2.3-dev.1, 1.2.3-dev.2등.
  • QA 채널: 1.2.3-qa.1, 1.2.3-qa.2등.
  • Staging 채널: 1.2.3-rc.1, 1.2.3-rc.2등.
  • Production 채널: 1.2.3, 1.2.4등.

Using semver와 pre-release 식별자 는 권장하는 방법이지만 엄격히 필요하지는 않습니다. 중요한 것은 빌드 간의 관계를 명확하게 전달하고 팀의 개발 프로세스와 일치하는 버전 관리 방식을 찾는 것입니다.

실시간 업데이트 롤백

실시간 업데이트 롤백

버그나 롤백이 필요한 실시간 업데이트가 배포되면 이전 빌드로 쉽게 롤백할 수 있습니다. 대시보드의 '채널' 섹션에서:

  1. 원하는 채널의 이름을 클릭합니다.
  2. 원하는 빌드를 찾고 crown 아이콘을 클릭합니다. 롤백 빌드
  3. 확인

선택한 빌드는 즉시 해당 채널의 활성 빌드로 다시 설정됩니다. 앱은 업데이트를 확인할 때 다음으로 롤백된 버전을 받습니다.

자동 배포

자동 배포

더 복잡한 워크플로우를 위해, 실시간 업데이트 배포를 CI/CD pipeline의 일부로 자동화할 수 있습니다. Capgo을 빌드 프로세스에 통합하면 특정 branch나 새로운 릴리스를 푸시할 때마다 자동으로 새로운 번들을 업로드하고 채널에 Assign할 수 있습니다.

체크 아웃 하세요 CI/CD 통합 docs to learn more about automating Capgo live updates.

권한이 제한된 PR 미리보기

권한이 제한된 PR 미리보기

사용하세요 __CAPGO_KEEP_0__ 키 API 키

  1. Have an organization administrator create a secure API key limited to the preview app and select __CAPGO_KEEP_0__ 키__CAPGO_KEEP_0__ 키 API 키.
  2. __CAPGO_KEEP_0__ pr-123__CAPGO_KEEP_0__ --default, --self-assign, --delete-linked-bundle-on-upload.
  3. ,
__CAPGO_KEEP_0__
APP_ID="com.example.app"
PREVIEW_CHANNEL="pr-123"
BUNDLE_VERSION="1.2.3-pr.123"
npx @capgo/cli@latest bundle upload "$APP_ID" \
--apikey "$CAPGO_PREVIEW_KEY" \
--path ./dist \
--channel "$PREVIEW_CHANNEL" \
--bundle "$BUNDLE_VERSION"
npx @capgo/cli@latest channel delete "$PREVIEW_CHANNEL" "$APP_ID" \
--apikey "$CAPGO_PREVIEW_KEY" \
--delete-bundle \
--success-if-not-found

bundle upload --channel __CAPGO_KEEP_0__

code

__CAPGO_KEEP_0__
npx @capgo/cli@latest app set "$APP_ID" --preview
npx @capgo/cli@latest get-qr "$APP_ID" --channel "$PREVIEW_CHANNEL" --apikey "$CAPGO_PREVIEW_KEY" --url

GitHub pull_request__CAPGO_KEEP_0__ pull_request_targetLive 업데이트를 위해, PRs를 같은 저장소에 제한합니다. github.event.pull_request.head.repo.full_name == github.repository.

장치에 배포하기

장치에 배포하기

채널에 대해 이해했다면, 실제 장치에 Live 업데이트를 배포하는 준비가 되었습니다. 기본적인 프로세스는 다음과 같습니다.

  1. 앱에 Capgo SDK을 설치합니다.
  2. 앱을 사용자 지정 채널에 연결하도록 구성합니다.
  3. 업데이트를 업로드하고 채널에 할당합니다.
  4. 앱을 실행하고 업데이트를 기다립니다!

자세한_walkthrough를 보려면 Live 업데이트를 배포하는 guide를 참조하세요. Happy updating! 고급 채널 사용: 사용자 구분

채널은 개발 단계만을 위한 것이 아닙니다. 채널은 사용자 구분을 위한 강력한 도구로, 다음과 같은 기능을 제공합니다:

  • 다양한 사용자 계층에 대한 기능 플래그
  • A/B 테스트
  • 기능 출시를 위한 점진적 출시
  • 베타 테스트 프로그램

이 고급 사용 사례를 구현하는 방법에 대한 안내를 참조하세요: 기능 플래그 및 A/B 테스트를 위한 사용자 구분과 채널을 사용하여 계획에 따라 사용자를 구분하는 방법.

채널에서 계속

채널에서 계속하기

채널을 사용하고 있다면 채널 채널 라우팅과 스테이지 롤아웃을 계획하고 채널 채널 채널 채널 베타 테스트 솔루션 채널 버전 대상 솔루션 채널 Capgo 환경 최적화: 단일 모바일 앱 ID로 스테이징 Capgo 환경 최적화: 단일 모바일 앱 ID로 스테이징