채널

이 Channel은 특정 앱의 JS 빌드 버전을 가리키며, 이 Channel을 듣기 위해 구성된 모든 장치에 업데이트를 공유합니다.

Live Update Channel은 앱의 특정 JS 빌드 버전을 가리키며, 이 Channel을 듣기 위해 구성된 모든 장치에 업데이트를 공유합니다. 앱에 __CAPGO_KEEP_0__ Live Updates __CAPGO_KEEP_1__을 설치하면, 해당 Channel을 구성된 모든 네이티브 바이너리는 앱이 실행될 때마다 업데이트가 있는지 확인합니다. Channel이 가리키는 빌드를 언제든지 변경할 수 있고, 이전 빌드로 롤백할 수도 있습니다. 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):

– 특정 장치 ID를 채널에 매핑하여 강제로 지정합니다. 긴급한 디버깅이나 단일 실제 사용자와 제어된 테스트에 사용합니다. __CAPGO_KEEP_0__은 마지막 override 쓰기 후 90일 후에 매핑을 삭제합니다. 자세한 내용은 콘솔 및 Capgo override가 90일 후에 만료됩니다. Cloud override (장치별) 대시보드 또는 API를 통해.
– 대시보드 또는 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.
플러그인 setChannel() 지역 채널 – 앱이 호출할 때 생성되며 setChannel() 백엔드가 대상 채널이 자체 할당을 허용하는지 확인하여 채널을 저장합니다. 선택한 채널은 즉시 적용되고 디바이스 오버라이드 UI에 표시되지 않습니다.

플러그인 버전 5.34.0, 6.34.0, 7.34.0, 또는 8.0.0부터 시작하여 (대부분 버전에 따라) setChannel() 백엔드와 통신하여 채널이 허용되는지 확인합니다. 자체 할당이 해당 채널에 대해 활성화되어 있는지 확인합니다. 채널을 저장합니다. Live Updates defaultChannel채널 이 채널이 다음 업데이트 확인 시 즉시 적용됩니다. 기존에는

채널 오버라이드가 백엔드 데이터베이스 (예: 대시보드 또는 __CAPGO_KEEP_0__ 변경 사항)에 저장되었고, 장치들은 데이터 복제가 완료될 때까지 (최대 2분) 새로운 채널이 인식될 때까지 기다려야 했습니다. setChannel() saved the channel override to the backend database (like Dashboard or API changes), and devices had to wait for data replication (up to 2 minutes) before the new channel was recognized. The new behavior only reads from the backend (for validation) and stores locally, making channel switches instant.

즉시 채널 Switch가 가능합니다. setChannel() 이것은 로컬 전용이기 때문에 create a Device Override entry in the Capgo dashboard. The Device Override UI only shows overrides created from the dashboard or the Public API.

Device Override UI는 대시보드 또는 Public __CAPGO_KEEP_1__에서만 오버라이드된 항목만 표시합니다. 주의:

중요: 대시보드 또는 API를 통해 채널 변경이 이루어질 때도, 모든 에지 서버가 변경을 반영하기까지 최대 2분의 시간 차이가 발생합니다. 즉시 채널 전환을 원한다면 setChannel() 앱에서 code를 사용하세요. 이 기능은 백엔드와 검증을 거친 후, 즉시 효과를 내는 채널 설정을 로컬에 저장합니다.

Capacitor 설정 defaultChannel (테스트 빌드 기본값) – __CAPGO_KEEP_0__에 존재하고, 강제/override/local 채널이 없다면, 앱은 이 채널에서 시작합니다. (예: ). 테스트 플라이트 / 내부 빌드에 사용하여, 테스터가 자동으로 프리-리리즈 채널에 접근할 수 있도록 합니다. 일반 프로덕션 빌드는 이 설정을 비워둡니다. capacitor.config.* 클라우드 기본 채널 (주요 경로 ~99%의 사용자) beta, qa, pr-123– 대시보드에서 기본 채널을 설정하면, 모든 일반 사용자(강제, 대시보드/ __CAPGO_KEEP_0__ override, 플러그인 로컬 채널, config defaultChannel가 없는 사용자)는 이 채널에 연결됩니다. 변경을 통해 즉시 배포하거나 되돌리세요. 새로운 바이너리가 필요하지 않습니다. 플랫폼별 기본값을 설정할 경우(예: iOS 전용, Android 전용, Electron 전용), 각 기기는 해당 플랫폼에 맞는 기본값으로 연결됩니다. 클라우드 기본 채널을 비워두는 것은 허용되며, 이 경우 기기는 1-4 단계를 통해 업데이트를 받습니다.
권장 사항: 1-4 단계를 예외/테스트層으로 간주하세요. 클라우드 기본 채널을 설정하면, 실제 사용자는 이 채널에 흐릅니다. 기본 채널을 설정하지 않는 경우, 사용자가 어떻게 연결되는지(일반적으로 API를 통해) 유의하여야 합니다.

클라우드 기본 채널 (주요 경로 ~99%의 사용자)

– 대시보드에서 기본 채널을 설정하면, 모든 일반 사용자(강제, 대시보드/ __CAPGO_KEEP_0__ override, 플러그인 로컬 채널, config defaultChannel가 없는 사용자)는 이 채널에 연결됩니다. 변경을 통해 즉시 배포하거나 되돌리세요. 새로운 바이너리가 필요하지 않습니다. 플랫폼별 기본값을 설정할 경우(예: iOS 전용, Android 전용, Electron 전용), 각 기기는 해당 플랫폼에 맞는 기본값으로 연결됩니다. 클라우드 기본 채널을 비워두는 것은 허용되며, 이 경우 기기는 1-4 단계를 통해 업데이트를 받습니다. defaultChannel 설정 또는 장치별 오버라이드에서 사용할 수 있습니다.
테스터에게 명시적으로 배포하는 바이너리에서만 구성해야 합니다. defaultChannel 생산 로직을 중앙에서 관리하기 위해 대시보드에서 설정을 비워두면 됩니다.
생산에서 적게 사용하고 QA 또는 특정한 디버깅 목적으로 주로 사용합니다. setChannel() 플랫폼(iOS/Android/Electron)에서 채널이 비활성화되어 선택될 경우, 채널 목록에서 건너 뛰고 다음 채널로 진행합니다.

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

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

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 장치 인벤토리 보존이것은 장치 인벤토리 제거와는 다릅니다. 장치가 90일 동안 Capgo에 연결하지 않은 경우 장치 인벤토리 제거는 장치가 활성화되어도 매핑을 삭제합니다.

이 assignment이 이 cleanup으로 제거되지 않는 경우:

설정 defaultChannel 설정 capacitor.config.* (재설치 시 살아남음; 이후 변경을 위해 새로운 네이티브 바이너리가 필요함).
콜 setChannel() 컨텍스트: Capgo UI의 더 긴 문자열에서 HTML 텍스트 프래그먼트 (부모 키 `appflow_migration_step2`). 페이지/영역: Appflow 비교/이동 마케팅 복사본. 역할: 웹사이트 복사본 문장. 페이지: ionic-appflow.astro. Capgo 제품/브랜드 및 개발자 용어를 정확하게 유지합니다. 메시지 키 `appflow_migration_step2` (Appflow Migration Step2). setChannel() 앱에서 호출합니다. 플러그인 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 및 이후 버전에서, assignment은 지역적이고 이 cleanup으로 제거되지 않습니다. 앱을 재설치하면 제거되므로, 앱이 다시 호출해야 합니다. 만약 그 채널을 여전히 원한다면.

__CAPGO_KEEP_0__ 채널 기기 API 채널 기기 탭과 기기 Override UI만 콘솔 및 Public API assignments을 표시합니다. 그들은 채널에 있는 모든 기기를 표시하지 않으며, 그들은 지역 setChannel() assignments.

Capgo 채널 기기 탭에 Override 보관소가 표시됩니다: 콘솔 오버라이드는 90일 후에 만료됩니다 — Override 보관소 알림이 채널 기기 탭에 표시됩니다.

기본 채널 동작

Cloudflare가 기본 채널로 설정되는 것은 선택사항이지만, 일반적으로 새로운 기기에 대한 기본 경로로 사용됩니다. 기본 채널이 없으면, 강제 매핑, 오버라이드, 또는 defaultChannel Capacitor config에 있는 매핑에 맞는 기기만 업데이트를 받습니다. 기본 채널을 설정할 때, 다음 패턴을 기억하세요:

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

빈칸을 예약하세요. 비生产 채널에 배포할 때 비生产 채널에서 시작하도록 하려면 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 생산 빌드에서는 빈칸으로 남겨두세요. 비생산 채널에 배포할 때 비생산 채널에서 시작하도록 하려면

생산 빌드에서는 빈칸으로 남겨두세요. 비생산 채널에 배포할 때 비생산 채널에서 시작하도록 하려면 생산 빌드에서는 빈칸으로 남겨두세요. 비생산 채널에 배포할 때 비생산 채널에서 시작하도록 하려면which takes you to 앱 정보. 기본값은 더 이상 채널 페이지에서 토글이 아닙니다. 채널을 바꿔서 새로운 장치들은 즉시 새로운 라우팅을 따르며 기존 장치들은 다음에 체크인할 때 정상적인 우선순위 규칙을 따릅니다.

채널 설정

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

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

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

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

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

채널이 생성되면, 채널에 맞게 앱을 구성해야 합니다. 이 예에서는 채널을 사용합니다. Development 채널을 사용하기 위해,

(또는 capacitor.config.ts ) 파일을 열어, capacitor.config.json부분에서, optionally 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 프로젝트에 복사하세요. config 파일을 동기화하지 않으면 이전에 구성된 채널을 사용하는 native 프로젝트가 계속 사용됩니다.

채널 옵션 및 전략

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

기본 채널: 새로운 장치가 연결될 때 채널 또는 플랫폼에 특정한 채널을 선택할 수 있습니다. 콘솔에서는 App Information(앱 설정 관리 채널 페이지에서 확인할 수 있습니다. 기본 채널 동작
라우팅 시나리오를 참조하십시오. iOS, Android플랫폼 필터: __CAPGO_KEEP_0__ 또는 __CAPGO_KEEP_1__에 대한 전달을 활성화하거나 비활성화할 수 있습니다. Electron 장치당 __CAPGO_KEEP_1__ 채널에 대한 전달을 활성화하거나 비활성화할 수 있습니다.
native 하위 버전을 비활성화: 장치의 native 앱 버전이 채널의 배포본보다 새로운 경우 업데이트를 보내지 않습니다. 예를 들어, 장치가 1.2.3 버전이고 채널이 1.2.2 버전인 경우.
개발 빌드 허용: 개발 빌드를 업데이트할 수 있도록 허용합니다. CLI: --dev / --no-dev.
생산 빌드 허용: 프로덕션 (스토어) 빌드에 업데이트를 허용하세요. 실제 사용자에게 서비스를 제공하는 채널의 경우 이 옵션을 유지하세요. CLI: --prod / --no-prod.
에뮬레이터 장치 허용: 에뮬레이터/시뮬레이터 (테스트에 유용)에 업데이트를 허용하세요. CLI: --emulator / --no-emulator.
물리 장치 허용: 실제 스마트폰 및 태블릿에 업데이트를 허용하세요. 프로덕션 채널의 경우 이 옵션을 유지하세요. CLI: --device / --no-device.
장치 자체 할당 허용: 앱이 런타임에 이 채널로 Switch할 수 있도록 허용합니다. 비활성화 시, __CAPGO_KEEP_0__: 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

Section titled “Progressive rollouts”

A 채널은 안정적인 번들을 유지하면서 점진적으로 고정 장치 그룹에 별도의 롤아웃 대상으로 노출할 수 있습니다. 모든 사용자에게 채널을 전환하지 않고도 일시 중단, 재개, 승격, 롤백 및 자동 실패 응답을 구성할 수 있습니다. 자세히 보기 진보적 롤아웃 for the delivery model, dashboard workflow, API fields, and CLI commands.

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

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

주 버전: 대상 번들의 주 버전이 장치의 원래 기준보다 높으면 차단합니다. 예시:version_build차단됩니다; 1.2.3 -> 2.0.0 허용됩니다. 1.2.3 -> 1.9.0 소 버전: 대상 번들의 주 버전 또는 소 버전이
소 버전: 대상 번들의 주 버전 또는 소 버전이 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 허용된다;
metadata: Require a minimum update version metadata on each bundle. Configure via CLI using --min-update-version 메타데이터: 각 번들을 위한 최소 업데이트 버전 메타데이터가 필요하다. __CAPGO_KEEP_0__을 사용하여 구성한다. --auto-min-update-version또는
없음: 모든 업데이트를 __CAPGO_KEEP_0__에 따라 허용한다. 없음: __CAPGO_KEEP_0__에 따라 모든 업데이트를 허용한다..

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

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

예시 (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

제목이 "Your App에서 setChannel() 사용"인 섹션

QA/디버그 메뉴에서 테스터가 채널을 전환할 수 있도록 해줍니다. setChannel() The

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

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

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

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

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

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

채널 변경 방법 비교:

방법	효과 시간	저장된 위치	기기 오버라이드 UI에서 표시	만료	사용 사례
`setChannel()` 플러그인에서	즉시	기기만(로컬)	아니오	아니오(변경하거나 재설치할 때까지)	사용자 앱 내 채널 Switching
기기 오버라이드 대시보드	2분 이내	백엔드 데이터베이스	네	마지막 override 쓰기 후 90일	특정 장치에 대한 관리자가 시작한 변경
API 채널 assign	2분 이내	백엔드 데이터베이스	네	마지막 override 쓰기 후 90일	자동화된 백엔드 통합

채널-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하는 방법

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의 "배포 집합" 섹션에서 빌드를 채널에 할당할 수 있습니다. 메뉴 아이콘을 클릭하고 "채널에 할당"을 선택하여 빌드에 채널을 선택하세요.

배포 집합 버전 및 채널

Capgo의 배포 집합은 앱에 전역적이지만, 채널에 특정적이지 않습니다. 동일한 배포 집합이 여러 채널에 할당될 수 있습니다.

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

채널 npx @capgo/cli@latest bundle upload --auto-bump __CAPGO_KEEP_0__ major, minor, patch/fix, metadata__CAPGO_KEEP_0__ aiCLI aiWorkers AI는 지역 vs 이전 delta 매니페스트에서 수준을 추론합니다 (이전 버전이 없으면 patch with no previous Capgo version). You cannot combine it with --bundleCI/CD 통합 와 참조 CLI reference.

빌드 간의 관계를 명확하게 전달합니다.

는 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.4등.

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

실시간 업데이트 롤백

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

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

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

자동 배포

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

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

권한이 제한된 PR 미리보기

CI/CD 통합에 사용하는 앱 미리보기 API 키를 사용하여 CI가 PR당 임시 채널을 생성해야 하지만 기존의 메인/기본 채널을 관리하지 않아야 함. 이 키는 소유한 조직과 선택한 앱에 묶여 있지만 조직 전체에서 역할을 수행하지는 않습니다. 생성된 각 비공개 미리보기 채널은 채널 스코프의 라이프 사이클 권한이 자동으로 부여됩니다.

조직 관리자가 미리보기 앱에만 제한된 API 키를 생성하고 앱 미리보기를 선택하세요. __CAPGO_KEEP_0__ 키에 대한 자세한 정보는 API 키.
__CAPGO_KEEP_0__ pr-123__CAPGO_KEEP_0__ --default, --self-assign__CAPGO_KEEP_0__ --delete-linked-bundle-on-upload.
__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

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_target그리고 동일한 저장소의 PR에 제한합니다. github.event.pull_request.head.repo.full_name == github.repository.

장치에 배포

채널을 이해한 후에, 실제 장치에 라이브 업데이트를 배포하기 위해 준비되었습니다. 기본 프로세스는 다음과 같습니다.

앱에 Capgo SDK을 설치합니다.
앱을 사용자 지정 채널에 수신하도록 구성합니다.
업데이트를 할당한 채널에 빌드를 업로드합니다.
앱을 실행하고 업데이트를 기다립니다!

세부적인_walkthrough를 보려면 라이브 업데이트를 배포하는 방법 guide를 참조하세요. 업데이트를 즐기세요!

고급 채널 사용: 사용자 구분

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

사용자 계층별로 기능 플래그를 설정
비교 테스트
기능 출시를 위한 점진적 출시
베타 테스트 프로그램

이 고급 사용 사례를 구현하는 방법에 대한 안내서를 참조하십시오: 기능 플래그와 A/B 테스트를 위한 사용자 구분 방법.

채널에서 계속

채널을 사용하고 있다면 채널 채널 라우팅과 스테이지 롤아웃을 계획하고 채널 채널 채널 채널 베타 테스트 솔루션 채널 버전 대상 솔루션 채널 Capgo 환경 최적화: 단일 모바일 앱 ID로 스테이징 for the practical context in Capgo Environment Best Practices: Staging with One Mobile App ID.