자연 OTA 채널 워크플로우

일반적인 Capgo 설정은 개발 채널 및 생산 채널을 사용합니다. CI는 OTA 번들을 업로드합니다. dev그 다음에는 업데이트를 production 준비가 되면 업데이트를 --fail-on-incompatible CI가 새로운 네이티브 code이 필요로 하는 live update을 실수로 배포하지 못하도록 한다.

이 페이지는 다음 질문에 대한 답변입니다. 업데이트를 의도적으로 채널의 현재 네이티브 패키지와 불일치하는 __CAPGO_KEEP_0__이 필요할 때

네이티브 패키지 비교에 대한 Capgo의 배경을 알고 싶다면 네이티브 호환성을 시작하세요. OTA vs Capgo 빌드가 자동으로 선택되는 CI branch를 전체적으로 보려면 자동 OTA 또는 네이티브.

추천 채널 레이아웃

이 안내서는 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 Live Update는 두 채널 모두에서 좋은 기본 설정입니다. 일상 OTA 업로드에 대한 설명입니다. 업로드 중인 버블에 포함된 네이티브 패키지를 현재 채널에 활성화된 버블의 네이티브 패키지와 비교합니다.그들이 다르면 업로드는 0이 아닌 값을 반환하고 nothing이 배포되지 않습니다.

일상 OTA (flag 유지)

JavaScript-only의 변경이 있을 때 네이티브 패키지가 채널과 일치할 때:

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

--fail-on-incompatible 네이티브 드리프트를 방지합니다. --auto-min-update-version 업로드할 때마다 채널이 Live Update를 사용하는 경우 __CAPGO_KEEP_0__이 필요합니다. metadata Live Update 전략을 사용하는 채널의 경우 업로드 전에 CI 게이트를 설정할 수 있습니다. metadata Live Update 전략을 사용하지 않는 채널의 경우 업로드 전에 CI 게이트를 설정할 수 없습니다. --auto-min-update-version Live Update 전략을 사용하는 채널의 경우 업로드 전에 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)

자발적 네이티브 버그 (플래그를 한 번만 사용하세요)

You cannot 업로드 한 번들을 업데이트된 네이티브 code가 필요합니다. --fail-on-incompatible. 그 플래그는 정확히 그 경우를 차단하기 위해 존재합니다. 플러그인, Capacitor 버전 또는 다른 네이티브 종속성이 의도적으로 변경되었을 때:

1. 해당하는 네이티브 바이너리 (애플 스토어 / 플레이 스토어, 또는 Capgo 빌드).
2. 해당하는 JS 번들 --fail-on-incompatible.
3. 없이 --auto-min-update-version 보다 metadata 채널을 strategy에 두어 기존 바이너리가 아직 설치되지 않은 기기에서 새로운 번들을 받지 못하도록 함.
4. 그 후 baseline 업로드 후, 다시 --fail-on-incompatible 일반적인 OTA CI (그리고 유지 --auto-min-update-version 채널이 유지되는 동안 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. 네이티브 바이너리를 배달하세요

   iOS/Android 앱을 빌드하고 제출하여 새로운 플러그인 또는 네이티브 변경 사항을 포함합니다. 사용자가 그 바이너리를 설치하기 전까지, 그들은 안전하게 네이티브 패키지를 의존하는 번들을 실행할 수 없습니다.

3. 업로드하는 매칭된 OTA 베이스 라인(이미) --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에서 유지해야 합니다. metadata 채널은 또한 유지해야 합니다. --auto-min-update-version.

FAQ

그렇다면 --fail-on-incompatible 자연스럽게 native-incompatible bundle을 밀 수 있나요?

자연스럽게 native-incompatible bundle을 밀 수 있나요? --auto-min-update-version 아니요. 업로드의 native 패키지가 채널의 live bundle과 다르면 플래그는 명시적으로 명령을 실패시킵니다. 의도적인 native 업데이트를 위해, 플래그를 제외하고 그 업로드에서 (그리고 사용할 수 있는 경우)

플래그 없이 한 번의 업로드는 올바른 접근 방법인가요?

플래그 없이 한 번의 업로드는 올바른 접근 방법인가요?

네. 새로운 바이너리를 배포한 후 채널의 native 기준을 업데이트하는 데 사용하는 지원된 방법입니다. 플래그를 다른 모든 OTA 업로드에 유지하여 CI에서 우발적인 native drift가 실패하도록 합니다. dev 처음에, 그 다음에 production?

네, 그게 당신의 프로세스와 일치하면. 같은 규칙을 적용한다 채널 당: 호환성 검사는 대상 채널에 현재 살아있는 것에 대해 수행된다. 프로모션 또는 다시 업로드를 production 만족할 때까지 dev 좋아 보인다면, 그리고 네이티브-베이스 라인 업로드 (아무것도) --fail-on-incompatible채널이 필요로 하는 새로운 네이티브 패키지를 기록하기 위해 각 채널에 대해.

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

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

어떤 플래그를 어떤 작업에 붙여야 하나요?

Path	When	업로드 플래그
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가 올바른 경로를 선택하도록 함

버전 목표

채널, semver 규칙, 배포 플로어의 메타데이터 전략

CLI: 패키지

__CAPGO_KEEP_0__: 번들

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

Native + OTA Channel Workflow를 사용 중이라면 네이티브 + OTA 채널 워크플로우 live updates를 native release 간에 안전하게 유지하기 위해 Native + OTA Channel Workflow를 네이티브 호환성 package 비교 규칙을 위해 자동 OTA 또는 네이티브 CI branching을 위해 버전 목표 context: Capgo 솔루션 마케팅 페이지. 역할: 섹션 또는 페이지 제목. 보이는 곳: 페이지 솔루션/버전-타겟팅.astro. 메시지 키 `solutions_version_targeting_title` (솔루션 버전 타겟팅 제목). | Capgo 솔루션 마케팅 페이지. 역할: 짧은 UI 레이블 또는 네비게이션 아이템. 보이는 곳: 사이트 헤더, 컴포넌트 SolutionsMegaMenu.astro, 페이지 솔루션/버전-타겟팅.astro. 메시지 키 `solutions_version_targeting` (솔루션 버전 타겟팅). Capgo CLI 패키지 참조 __CAPGO_KEEP_0__ __CAPGO_KEEP_1__