채널

복사할 수 있는 명령어

Live Update 채널은 특정 JS 번들 빌드에 대한 링크를 제공하며, 이 채널을 듣기 위해 구성된 모든 기기에 업데이트를 공유합니다. Live Updates __CAPGO_KEEP_1__을 앱에 설치하면, 채널에 구성된 모든 네이티브 바이너리는 앱이 시작될 때 업데이트가 있는지 확인합니다. 채널이 가리키는 빌드를 언제든지 변경할 수 있고, 이전 빌드로 롤백할 수도 있습니다. install the Capgo Live Updates SDK 채널은 업데이트를 제어하지만, 번들을 보호하지 않습니다. 채널이 개인화되거나 자체 할당이 비활성화되어도, __CAPGO_KEEP_0__에 업로드된 암호화되지 않은 번들은 여전히 공개 자산으로 취급되어야 합니다. 암호화는 업데이트를 전달하는 경로와 authenticity를 보호하지만, 배포된 번들은 여전히 클라이언트의 공개 키를 사용하여 역 엔지니어링될 수 있습니다. 자세한 내용은

장치가 채널을 선택하는 방법 (우선 순위)

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

– 특정 장치 ID를 채널에 고정하여 사용합니다. 긴급한 디버깅이나 단일 실제 사용자와 제어된 테스트에 사용합니다. 항상 우선합니다. Cloud override (per-장치) via 대시보드 또는 __CAPGO_KEEP_0__
– 대시보드 또는 API에서 장치의 채널을 변경할 때 생성됩니다. QA 사용자가 기능/PR 채널 또는 사용자 문제를 재현하기 위해switching합니다. 바이너리 재설치로 지워지지 않으며, 장치 항목 삭제로 지워집니다. – 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 entry does.
지역 채널 setChannel() – 앱이 호출할 때 생성됩니다. 채널 우선 순위 setChannel() 그리고 백엔드가 대상 채널이 자체 할당을 허용하는지 확인합니다. 선택한 채널은 해당 장치에 저장되어 즉시 적용되고 장치 오버라이드 UI에서 표시되지 않습니다.

플러그인 버전 5.34.0, 6.34.0, 7.34.0, 또는 8.0.0부터 시작하여 (당신의 주요 버전에 따라) setChannel() 다르게 작동합니다: 백엔드에 접속하여 유효성을 검사합니다. 자체 할당이 대상 채널에 대해 허용되는지 확인합니다. 그런 다음 장치에 채널을 저장합니다. 장치에 저장된 채널 이것입니다. defaultChannel이 새로운 채널은 즉시 적용됩니다. 이것입니다. 다음 업데이트를 확인하기 위해 대기하지 마세요.

그 이전에 setChannel() 채널 오버라이드가 백엔드 데이터베이스 (대시보드나 API 변경과 같이)로 저장되었고, 장치들은 데이터 복제가 완료될 때까지 (2분 이내) 새로운 채널이 인식될 때까지 기다려야 했습니다. 새로운 동작은 백엔드에서만 읽어 (유효성 검사)하고 로컬에 저장하기 때문에 채널 Switch가 즉시 발생합니다.

그런 이유로 setChannel() 로컬 전용이기 때문에 __CAPGO_KEEP_0__ 대시보드에 장치 오버라이드 항목을 생성하지 않습니다. 장치 오버라이드 UI에서는 대시보드나 Public __CAPGO_KEEP_1__에서만 생성된 오버라이드만 표시됩니다. create a Device Override entry in the Capgo dashboard. The Device Override UI only shows overrides created from the dashboard or the Public API.

채널이 로컬에서 설정된 후 허용되지 않게 된 경우에도 백엔드는 업데이트를 확인할 때 채널을 유효성 검사하므로 보안이 유지됩니다. 중요:

대시보드나 __CAPGO_KEEP_0__에서 채널 변경이 이루어질 때에도 모든 에지 서버가 변경을 반영하기까지 2분 이내의 복제 지연이 발생합니다. 즉시 채널 Switch를 사용하려면 앱에서 API를 사용하세요. - 백엔드와 유효성 검사를하고, 즉시 효과를 위해 로컬 채널을 설정합니다. setChannel() code

Capacitor 설정 defaultChannel (테스트 빌드 기본) – 만약에 존재한다면 capacitor.config.* 그리고 강제/override/지역 채널이 없다면, 앱은 이 채널에서 시작한다 (예: beta, qa, pr-123). 테스트 플라이트 / 내부 빌드에 사용하여 테스터가 자동으로 미리 출시 채널에 도착하도록 한다. 프로덕션 빌드는 일반적으로 이 설정을 비워둔다.
클라우드 기본 채널 (주요 경로 ~99%의 사용자) – 만약에 대시보드에서 기본 채널을 표시한다면, 모든 일반 사용자 (강제, 대시보드/ API override, 플러그인 지역 채널, 설정 기본 채널이 없는 경우) 여기로 연결된다. 이 채널을 변경하면 즉시 배포 또는 롤백할 수 있다 – 새로운 바이너리가 필요하지 않다. 플랫폼별 기본값 (예: iOS 전용, Android 전용, Electron 전용)을 설정한 경우 각 기기는 해당 플랫폼에 맞는 기본값으로 연결된다. 클라우드 기본 채널을 비워두는 것은 허용되며, 그 경우 기기는 1-4 단계를 따라야 업데이트 받을 수 있다.

최선의 방법:

1-4 단계를 테스트/예외 계층으로 처리하라; 대시보드에서 클라우드 기본 채널을 설정하면 실제 사용자가 이 채널로 흐르게 된다. 클라우드 기본 채널을 설정하지 않으면, 사용자가 연결하는 방법에 대해 명확해야 한다 (일반적으로 defaultChannel 설정 또는 기기별 override)
만약에 defaultChannel 을 설정한다면, 테스트에 사용하는 바이너리에서만 설정하라. 클라우드 기본 채널을 비워두면 프로덕션 로직이 중앙에 유지된다.
사용 setChannel() 생산 환경에서 적게 사용하세요—주로 QA 또는 특정 진단 목적으로 사용합니다.

플랫폼 (iOS/Android/Electron 토글)에서 채널이 비활성화되어 선택될 경우, 목록에서 건너 뛰어 다음 항목으로 계속 진행합니다.

요약: 강제 > 대시보드/API Override > 플러그인 setChannel() 지역 채널 > 설정 defaultChannel > Cloud 기본값.

기본 채널 동작

설정된 클라우드 기본값은 선택사항이지만, 새로운 장치의 기본 경로로 사용됩니다. 기본값이 없으면, 강제 매핑, Override, 또는 __CAPGO_KEEP_0__ config에 있는 패턴에 맞는 장치만 업데이트를 받습니다. 기본값을 설정할 경우, 다음 패턴을 고려하세요: defaultChannel in the Capacitor config will receive updates. When you do choose to mark defaults, keep these patterns in mind:

– iOS, Android, Electron이 모두 활성화된 채널이 단일 기본값이 됩니다. Override가 없는 장치들은 이 기본값에 연결됩니다. –
플랫폼별 기본값 – 플랫폼별로 채널을 나누면 (예를 들어, iOS만 활성화, Android만 활성화, Electron만 활성화), 각 플랫폼별 기본값으로 표시합니다. iOS 기기는 iOS 기본값으로, Android 기기는 Android 기본값으로, Electron 앱은 Electron 기본값으로 이동합니다. ios-production 기억하십시오. 클라우드 기본값과 android-production both electron-production 같은 결정 계층을 차지합니다. 클라우드 기본값을 설정하면 __CAPGO_KEEP_0__ 구성에서 값을 중복해서 입력할 필요가 없습니다—생산 빌드에서는 빈칸으로 남겨두십시오. 테스터나 QA에게 배포할 때 비정상 채널로 시작하도록 하려면

해당하는 바이너리만 예약해 두십시오. 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 채널

기본값

기기

온보딩 중에 첫 번째 채널을 생성합니다(대부분의 팀은 '생산'이라고 이름 지웁니다). 그러나 모든 것이 잠금 해제되어 - 채널을 언제든지 이름을 바꾸거나 삭제할 수 있습니다. 추가 채널을 생성하려면:

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

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

Development - 로컬 장치 또는 시뮬레이터에서 실시간 업데이트 테스트
QA - QA 팀이 더 넓은 릴리스 전에 업데이트 확인
Staging - 실제 환경과 유사한 환경에서 최종 테스트
Production - 앱 스토어에서 사용자에게 제공되는 앱 버전

앱에서 채널 구성

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

파일을 열어보세요. capacitor.config.ts (또는) capacitor.config.json섹션 아래에서, 옵션적으로 plugins 를 defaultChannel 테스트 빌드 (내부 / QA) 로 설정하세요. 프로덕션 빌드의 경우, 생략하여 디바이스가 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.
    },
  },
};

를 실행하여 iOS, Android, Electron 프로젝트에 업데이트된 config 파일을 복사하세요. 이 동기화 단계를 생략하면, 이전에 구성된 채널을 계속 사용하는 native 프로젝트가 계속됩니다. npx cap sync Copy to clipboard

채널 옵션 및 전략

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

기본 채널: 새로운 장치가 연결될 때 채널 또는 플랫폼에 특정한 채널을 선택적으로 표시합니다. "기본 채널 동작"을 참조하여 라우팅 시나리오를 확인하세요.
플랫폼 필터: iOS, Android또는 Electron 채널당 장치 수를 제어합니다.
네이티브 자동 다운그레이드 비활성화: 장치의 네이티브 앱 버전이 채널의 패키지 버전보다 새로운 경우 업데이트를 보내지 않습니다 (예: 장치 버전 1.2.3, 채널 버전 1.2.2).
개발 빌드 허용: 개발 빌드를 업데이트하도록 허용합니다 (테스트에 유용합니다).
에뮬레이터 장치 허용: 에뮬레이터/시뮬레이터에 대한 업데이트를 허용합니다 (테스트에 유용합니다).
장치 자체 할당 허용: 런타임에 이 채널로 Switch를 허용합니다. 만약 비활성화되면 setChannelwill fail for this channel. setChannel 진보적 롤아웃

진보적 롤아웃

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

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

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

major: 장치의 원래 기준보다 높은 메이저 버전을 가진 대상 번들이 차단됩니다. 예시:version_build차단됩니다; 1.2.3 -> 2.0.0 허용됩니다. 1.2.3 -> 1.9.0 minor: 대상 번들이 메이저 또는 미니 버전이 다르면 차단됩니다. 예시:
차단됩니다; version_buildmajor: 장치의 원래 기준보다 높은 메이저 버전을 가진 대상 번들이 차단됩니다. 예시: 차단됩니다; 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__에 따라 __CAPGO_KEEP_1__ 호환성을 기준으로 모든 업데이트를 허용합니다. __CAPGO_KEEP_0__ : __CAPGO_KEEP_1__.

이 전략은 채널의 목표 번들을 원시 기준선과 비교합니다. __CAPGO_KEEP_0__ version_build현재 다운로드한 번들을 __CAPGO_KEEP_0__ version_name.

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

예(CLI):

# 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

Your App에서 setChannel() 사용

이 메소드는 앱이 런타임에 채널을 프로그래밍적으로switch할 수 있도록합니다. 이 기능은 특히: setChannel() QA/테스트 메뉴에서 테스터가 채널을 switch할 수 있도록하는 경우

베타 프로그램 옵인 플로우
이
기능 플래그 구현
AB 테스트 시나리오

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

언제 setChannel() 호출되는 경우:

백엔드 유효성 검사 (읽기 전용): Capgo 백엔드에 요청을 보내서 채널이 허용되는지 확인합니다 (자신의 할당 권한을 확인합니다)
로컬 스토리지 업데이트: 유효성 검사가 통과되면, 채널은 장치의 로컬 스토리지에 저장됩니다 defaultChannel
즉시 효과: 다음 업데이트 체크는 새로운 채널을 즉시 사용합니다 (복제 대기 없음)

왜 이것이 중요합니까? 오래된 버전에서 setChannel() 저장된 채널 오버라이드가 백엔드 데이터베이스에 저장되었습니다 (같은 Dashboard 또는 API 변경과 같습니다). 장치들은 백엔드 복제 대기 (최대 2분)가 끝나기 전에 채널 변경이 적용되었습니다. 이제 setChannel() 백엔드에서만 읽고, 로컬에서만 저장하여 채널 Switch가 즉시 적용됩니다.

Dashboard 표시: 플러그인으로 설정된 채널은 Capgo UI에서 장치 오버라이드로 나타나지 않습니다. 채널 assignments만 dashboard 또는 Public API에서 생성된 경우에만 목록에 표시됩니다. Dashboard 또는 API를 사용하여 관리자가 볼 수 있는 오버라이드를 필요로 할 때입니다.

보안 주의: 채널의 권한이 로컬에서 변경되더라도 (예: 자체 할당이 비활성화된 경우), 백엔드에서 채널을 업데이트 체크 시 유효성 검사를 수행하여 보안을 유지합니다.

채널 변경 방법 비교:

방법	효과 시간	persisted where	device override ui에서 표시	사용 사례
`setChannel()` 플러그인에서	즉시	장치만(로컬)	아니오	사용자 앱 내 채널 Switching
장치 override 대시보드	2분 이내	백엔드 데이터베이스	예	장치별 특정 장치에 대한 관리자가 시작한 변경 사항
API 채널 할당	최대 2분	백엔드 데이터베이스	네	자동화된 백엔드 통합

사용자 경험을 최적화하기 위해 채널-switching UI를 구축할 때 항상 플러그인의 setChannel() 메소드를 사용하세요.

지역 전용 채널 switching에 대한 최소 버전: 5.34.0, 6.34.0, 7.34.0또는 8.0.0 (대형 버전에 따라 다름). 각 소수 버전 번호는 모든 대형 버전에서 동일한 기능 집합을 나타냅니다 (예: X.34.0은 X가 5, 6, 7 또는 8이더라도 동일한 기능을 포함합니다). 플러그인 설치 버전 태그를 위해.

채널에 번들을 Assign하는 방법

라이브 업데이트 배포를 위해, 새로운 JS 번들을 업로드하고 채널에 Assign해야 합니다. Capgo CLI 단계에서 한번에 이 작업을 수행할 수 있습니다.

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

이 작업은 웹 자산을 업로드하고 채널에 대한 새로운 번들을 활성화합니다. 채널에 연결된 앱은 다음 업데이트를 확인할 때 업데이트를 받습니다. Development __CAPGO_KEEP_0__ 대시보드의 “번들” 섹션에서 채널에 번들을 Assign할 수도 있습니다. 메뉴 아이콘을 클릭하고 “채널 Assign”을 선택하여 해당 번들을 Assign할 채널을 선택하세요.

You can also assign builds to channels from the “Bundles” section of the Capgo dashboard. Click the menu icon next to a build and select “Assign to Channel” to choose the channel for that build.

Section titled “번들 버전 및 채널”

Capgo

버전 관리할 때, __CAPGO_KEEP_0__의 Semver Tester와 channel-specific 빌드에 대한 pre-release 식별자와 함께 semantic 버전 관리를 사용하는 것을 권장합니다. Capgo의 channel 링크된 번들을 Capgo 버전이 업로드된 경우, CI에서 로컬 버전이 이미 업로드된 경우, Capgo 버전을 업데이트할 때 사용합니다. (선택적으로) 1.2.3-beta.1.

, 또는) npx @capgo/cli@latest bundle upload --auto-bump 로 __CAPGO_KEEP_0__ 버전을 업데이트할 때 사용합니다. __CAPGO_KEEP_0__ 버전이 업로드된 경우, __CAPGO_KEEP_0__ 버전을 업데이트할 때 사용합니다. major, minor, patch/fix, metadata__CAPGO_KEEP_0__ 버전이 업로드된 경우, __CAPGO_KEEP_0__ 버전을 업데이트할 때 사용합니다. aiCLI 버전이 업로드된 경우, CLI 버전을 업데이트할 때 사용합니다. ai__CAPGO_KEEP_0__ 버전이 업로드된 경우, __CAPGO_KEEP_0__ 버전을 업데이트할 때 사용합니다. patch Capgo 버전이 업로드된 경우, Capgo 버전을 업데이트할 때 사용합니다. --bundle__CAPGO_KEEP_0__ 버전이 업로드된 경우, __CAPGO_KEEP_0__ 버전을 업데이트할 때 사용합니다. __CAPGO_KEEP_0__ 버전이 업로드된 경우, __CAPGO_KEEP_0__ 버전을 업데이트할 때 사용합니다. __CAPGO_KEEP_0__ 버전이 업로드된 경우, __CAPGO_KEEP_0__ 버전을 업데이트할 때 사용합니다. CLI 참조.

이 접근 방식에는 여러 이점이 있습니다:

빌드 간의 관계를 명확하게 전달합니다. 1.2.3-beta.1 명백히는 이전 버전입니다. 1.2.3.
여러 채널에서 버전 번호를 재사용할 수 있으므로 혼란을 줄입니다.
역할백 경로를 명확하게 활성화합니다. 이전 버전으로 롤백해야 하는 경우 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.4Using

pre-release 식별자와 함께 semver 사용하는 것은 권장되는 방법이지만, 엄격히 필요하지는 않습니다. 중요한 것은 빌드 간의 관계를 명확하게 전달하고 팀의 개발 프로세스와 일치하는 버전 관리 방식을 찾는 것입니다. 실시간 업데이트 롤백 제목: 실시간 업데이트 롤백

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

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__
원하는 빌드를 찾고 crown 아이콘을 클릭하세요.
작업을 확인하세요

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

자동 배포

더 복잡한 워크플로우를 위해, CI/CD pipeline에 Capgo을 통합하여 live update 배포를 자동화할 수 있습니다. 빌드 프로세스에 Capgo을 통합하면 특정 branch로 푸시하거나 새로운 릴리즈를 만들 때마다 새로운 배ंडल을 자동으로 업로드하고 채널에 할당할 수 있습니다.

CI/CD 통합 CI/CD 통합 CI/CD 통합에 대한 더 자세한 내용은 Capgo live update를 자동화하는 방법에 대해 알아보세요.

최소 권한 PR 미리보기

CI를 사용하는 경우 앱 미리보기 API

Have an organization administrator create a secure API key limited to the preview app and select 조직 관리자가 미리보기 앱에만 제한된 보안 __CAPGO_KEEP_0__ 키를 생성하고 선택하세요.앱 미리보기 API 키.
미리보기 앱에만 제한된 유니크한 비공개 채널을 사용하세요. pr-123__CAPGO_KEEP_0__ 키 --default, --self-assignrollout 옵션, 또는 --delete-linked-bundle-on-upload.
PR 번들 업로드 및 승격을 한 명령어로 처리하고 PR가 닫히면 소유한 채널과 번들을 삭제하세요:

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 채널이 없으면 채널을 생성하고 패키지를 업로드하고 이를 하나의 흐름으로 승격합니다. 정리도 원자적이고 소유권이 확인됩니다: 키는 자신이 생성한 채널과 연결된, 공유되지 않은 패키지만 삭제할 수 있습니다. 기존의 기본 채널, 다른 미리보기를 위한 키의 채널, 다른 키의 패키지를 변경하거나 승격하거나 삭제할 수 없습니다.

리뷰어들이 QR 코드 code 또는 미리보기를 위한 URL이 필요하면 앱에 대한 미리보기를 활성화해야 합니다:

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

App Preview 키는 미리보기를 활성화할 수 없습니다. 미리보기를 활성화하는 데 필요한 앱 설정 권한이 없기 때문입니다. GitHub Actions에서, secret-bearing preview jobs를 실행하고 pull_request, pull_request_target, github.event.pull_request.head.repo.full_name == github.repository.

,

기기로 배포하는 것을

Install the Capgo SDK in your app
__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__
Beta testing programs

이 기능을 구현하는 방법에 대한 안내를 받으려면 기능 플래그 및 A/B 테스트를 위해 사용자들을 계획과 채널로 구분하는 방법.

Channels에서 계속 진행하세요

Channels을 사용하여 Channels Channels과 연결하여 Channels Channels과 연결하여 Channels에서 구현 세부 정보를 확인하세요 Channels에서 구현 세부 정보를 확인하세요 Beta 테스트 솔루션 Beta 테스트 솔루션의 제품 워크플로우에 대해 버전 목표 솔루션 버전 목표 솔루션의 제품 워크플로우 및 Capgo 환경 최적화: 단일 모바일 앱 ID로 스테이징 Capgo 환경 최적화: 단일 모바일 앱 ID로 스테이징에 대한 실제 맥락에 대해