네이티브 + OTA 채널 워크플로우

일반적인 Capgo 설정은 개발 생산 context 채널. CI는 OTA 번들을 업로드하고 dev, 그리고 production 준비가 되면 --fail-on-incompatible so CI cannot ship a live update that needs new native code by accident.

이러한 오류를 방지하기 위해 CI가 실시간 업데이트를 배포할 때 새로운 네이티브 __CAPGO_KEEP_0__이 필요하지 않도록 하기 위해 이 페이지는 다음 질문에 대한 답변입니다: 실시간 업데이트를 배포할 때

If you need the background on why Capgo compares native packages, start with 실시간 업데이트를 배포할 때. For a full CI branch that picks OTA vs Capgo Build automatically, see 실시간 업데이트를 배포할 때.

권장 채널 레이아웃

이 안내서에서는 dev 그리고 production 채널이 이미 존재한다고 가정합니다. 필요 시 먼저 만들기:

npx @capgo/cli@latest channel add production com.example.app
npx @capgo/cli@latest channel add dev com.example.app

채널	누가 받는가	일반적인 업로드
dev	내부 / QA 빌드	JS (및 의도적인 네이티브 베이스 라인) 의 각 CI 푸시
production	스토어 사용자	릴리즈 준비가 된 경우에만 업로드

--fail-on-incompatible 두 채널 모두에서 좋은 기본 설정입니다. 일상 OTA 업로드. 업로드 중인 버너에 포함된 네이티브 패키지를 현재 채널에 살아있는 버너의 패키지와 비교합니다. 패키지가 다르면 업로드는 0이 아닌 값을 반환하고 배포되지 않습니다.일상 OTA (플래그 유지)

일상 OTA (플래그 유지) 섹션

터미널 창

npx @capgo/cli@latest bundle upload com.example.app \
  --channel production \
  --fail-on-incompatible \
  --auto-min-update-version

--fail-on-incompatible blocks 의도하지 않은 네이티브 드리프트. --auto-min-update-version 업로드에 필요합니다. 채널이 Cloudflare의 네이티브 OTA 채널 워크플로를 사용하기 시작한 후에. metadata 전략 (아래에 권장하는 것)을 사용하는 경우. 채널이 아직 Cloudflare의 네이티브 OTA 채널 워크플로를 사용하지 않는 경우, metadata 아직은 생략할 수 있습니다. --auto-min-update-version 업로드 전 CI 게이트 (선택사항):

터미널 창

npx @capgo/cli@latest bundle releaseType com.example.app --channel production
# → OTA      safe to upload with --fail-on-incompatible
# → native   stop; ship a native binary first (see below)

네이티브 버그를 의도적으로 발생시킵니다 (플래그를 한 번만 사용합니다).

Cloudflare의 네이티브 OTA 채널 워크플로를 사용하기 시작한 후에 업로드에 필요합니다. 업로드 전 CI 게이트 (선택사항): 터미널 창, 클립보드 복사, 네이티브 버그를 의도적으로 발생시킵니다 (플래그를 한 번만 사용합니다). 새로운 네이티브 code가 필요하다는 code 업로드 --fail-on-incompatible. 이 플래그는 정확히 그 경우를 막기 위해 존재합니다. 플러그인, Capacitor 버전 또는 다른 네이티브 의존성이 의도적으로 변경되었을 때:

1. 새로운 __CAPGO_KEEP_0__ 버전을 배포 네이티브 바이너리 (애플 스토어 / 플레이 스토어, 또는 __CAPGO_KEEP_0__ 빌드) __CAPGO_KEEP_0__ 빌드 새로운 Capgo 버전과 일치하는 JS Capgo 업로드).
2. 업로드하지 마세요 기호를 사용하여 __CAPGO_KEEP_0__ 채널을 __CAPGO_KEEP_0__ 전략에 두세요. 기존 바이너리가 아직 설치되지 않은 기기에서 새로운 __CAPGO_KEEP_0__를 받지 않도록 하세요. --fail-on-incompatible.
3. 기본선 업로드 후에 --auto-min-update-version __CAPGO_KEEP_0__ 업로드 후에 metadata __CAPGO_KEEP_0__ 업로드 후에
4. __CAPGO_KEEP_0__ 업로드 후에 --fail-on-incompatible CI (정상 OTA)로 돌아가고 --auto-min-update-version While the channel stays on metadata).

1. 한 번에 채널당: 메타데이터 게이트를 활성화

   npx @capgo/cli@latest channel set production com.example.app --disable-auto-update metadata

   위의 단계를 반복하여 dev 만약 그 채널이도 의도적으로 네이티브 베이스 라인도 받는다면 --auto-min-update-version 또는 --min-update-version.

2. 이러한 Switch 후, 채널에 업로드하는 모든 업데이트는

   또는

3. 터미널 창 --fail-on-incompatible)

   npx @capgo/cli@latest bundle upload com.example.app \
     --channel production \
     --auto-min-update-version

   이 채널에 새로운 네이티브 패키지를 기록합니다. 나중에 bundle releaseType / --fail-on-incompatible 체크는 그 기준선에 의존합니다.

4. 보호된 OTA 업로드를 재개합니다

   후속 JS-만의 릴리스는 다시 두 가지 플래그를 사용합니다:

   npx @capgo/cli@latest bundle upload com.example.app \
     --channel production \
     --fail-on-incompatible \
     --auto-min-update-version

팁

네이티브 기준선 업로드를 기존 CI 작업과 다르게 기본 OTA 작업에 예외로 넣지 마십시오. 기본 작업은 항상 --fail-on-incompatible, 그리고 channel 에서도 metadata channel 에서도 --auto-min-update-version.

FAQ

Section titled “FAQ” --fail-on-incompatible 그리고 여전히 native-incompatible bundle 을 push 할 수 있나요?

아니요. 업로드의 native 패키지가 channel의 live bundle과 다르면 flag은 명시적으로 명령을 실패시킵니다. 의도적인 native 업데이트를 위해, flag을 제외하고 한 번의 업로드를 수행하세요 (그리고 --auto-min-update-version when you can)

그것이 올바른 접근 방법인가요?

네. 새로운 바이너리를 배포한 후 channel의 native 기본값을 업데이트하는 데 사용하는 지원된 방법입니다. 다른 모든 OTA 업로드에서 flag을 유지하여 CI에서 우발적인 native drift가 실패하도록 하세요.

업로드를 dev에 먼저하고 그 다음에 production에 업로드해야 하나요? dev 첫째, 둘째 production?

네, 그게 당신의 프로세스와 일치하면 됩니다. 같은 규칙을 적용하여 채널당: 호환성 검사는 대상 채널에 현재 업로드된 내용과 비교합니다. 새로운 네이티브 패키지를 기록하기 위해 production 업로드를 dev 만족스럽게 보이면, 그리고 네이티브-베이스 라인 업로드를 사용하여 --fail-on-incompatible) 각 채널에서 새로운 네이티브 패키지를 기록합니다.

새로운 네이티브 번들을 플래그가 여전히 켜져 있는 상태로 업로드하면 어떻게 하나요?

CI가 실패하고 Capgo은 그 업로드를 배포하지 않습니다. 그게 예상되는 결과입니다. 변경이 의도치 않게 이루어졌을 경우 (네이티브 패키지를 수정하고 OTA로 다시 시도하세요), 또는 의도적으로 이루어졌을 경우 (위의 네이티브 경로를 사용하세요).

어떤 플래그가 어떤 작업에 붙을까?

경로	언제	플래그 업로드
OTA	JS만; 네이티브 패키지는 채널에 맞춰진다	--fail-on-incompatible + --auto-min-update-version (채널이 활성화된 경우 필수) metadata)
네이티브 베이스 라인	새로운 네이티브 바이너리 + 채널에 맞춰진 JS 번들	아니오 --fail-on-incompatible; 유지 --auto-min-update-version

관련

자연 호환성

Capgo이 네이티브 패키지 드리프트를 감지하고 장치에 대한 불일치가 무엇인지 설명합니다.

자동 OTA 또는 네이티브

Wire bundle releaseType GitHub 액션 또는 GitLab에 들어가 CI가 올바른 경로를 선택하도록 합니다.

버전 목표

페이지/영역: Capgo 솔루션 마케팅 페이지. 역할: 섹션 또는 페이지 제목. 보는 곳: page solutions/version-targeting.astro. 메시지 키 `solutions_version_targeting_title` (솔루션 버전 목표 제목). | 페이지/영역: Capgo 솔루션 마케팅 페이지. 역할: 짧은 UI 레이블 또는 네비게이션 아이템. 보는 곳: page solutions/version-targeting.astro. 메시지 키 `solutions_version_targeting` (솔루션 버전 목표).

CLI: bundle

__CAPGO_KEEP_0__: 번들

업로드, 호환성, releaseType 및 관련 플래그에 대한 참조.

만약 당신이 사용 중이라면 Native + OTA 채널 워크플로우 live 업데이트를 native 릴리즈에 안전하게 유지하기 위해 Native + OTA 채널 워크플로우를 연결하세요. Native 호환성 패키지 비교 규칙에 대해 Auto OTA 또는 Native CI branch에 대해 버전 목표 메타데이터 floor에 대해, 그리고 Capgo CLI 배포 참조 업로드 플래그에 대해.