Capgo 클라우드 기본 채널이 장치 업데이트를 수행하지 않는다?

__CAPGO_KEEP_0__ 기본 채널을 변경하는 중입니다. Capgo 새로운 장치에 바로 연결합니다. 기존 설치는 다시 확인할 때까지 이전 채널에 머물 수 있습니다. 이는 Capgo cloud default channel이 장치 업데이트를 하지 않는 많은 경우를 설명합니다.

체크를 순서대로 진행하세요. 장치 할당을 확인한 후 앱 빌드, 동기화 상태, 롤아웃 규칙, 로그, 롤백 설정을 검사하세요.

목차

• 1단계: 기본 채널에 할당된 장치가 있는지 확인하세요.
• 2단계: 앱, 네이티브 런타임, 업데이트 호환성을 확인하세요.
• 3단계: 배포가 실제로 기본 채널에 도달했는지 확인하세요.
• 4단계: 최신 동기화를 강제하고 장치 측 로그를 검사하세요.
• 5단계: 롤아웃 규칙, 버전 게이트, 자동 롤백을 검토하세요.
• 6단계: 실시간 분석을 사용하여 정확한 실패 지점을 찾으세요.
• 7단계: 기본 채널이陈舊하지 않도록 방지하세요.
• FAQ
• 결론

Step 1: 장치가 기본 채널에 할당되어 있는지 확인하세요.

기본 채널이 적용되는 목표는 기존에 장치가 할당된 채널을 강제로 할당하는 경우가 아니면 Cloud Default를 적용하는 것입니다.

Capgo 대시보드를 열고 영향을 받은 장치를 검사하세요. 현재 채널, 앱 ID, 버전, 마지막 체크인 시간을 확인하세요. 기대하는 업데이트를 받은 장치의 값을 비교하면 문제를 빠르게 찾을 수 있습니다.

채널 선택은 순서에 따라 결정됩니다. 강제 채널은 우선순위가 가장 높습니다. 대시보드 또는 API 장치 오버라이드가 다음 순위입니다. 앱이 설정한 로컬 채널이 그다음입니다. 그 다음 Capgo이 native 앱 설정에서 확인합니다. Cloud Default는 기본값입니다.defaultChannel이 순서는 장치가 Cloud Default가 변경되었음에도 불구하고 에러 없이 기본 채널을 무시할 수 있게 해줍니다. 예를 들어 테스트 빌드가 이전 테스트에서 설정한 로컬 채널을 계속 사용할 수 있습니다. 앱은 그 채널을 사용할 때까지 로컬 채널을 유지합니다.

__CAPGO_KEEP_0__ 업데이터 디버깅 가이드를 사용하세요. 채널이 비어 있거나 예상치 못한 채널이 나타날 때입니다. 이 가이드는 앱이 사용할 수 있는 기본 채널이 없고 장치가 오버라이드가 없을 때를 위한 것입니다.

다음으로 __CAPGO_KEEP_0__ 설정을 확인하세요. 일반적인 설정은 다음과 같습니다. 이 필드는 선택 사항입니다. 필드를 생략하면 장치는 Cloud Default를 상속할 수 있습니다. 이는 프로덕션 빌드에 적합합니다. 채널 라우팅은 Capgo Cloud에서 유지되기 때문입니다. 필드를 포함하면 실제로 배포한 채널과 일치하는지 확인하세요. Step 1: 장치가 기본 채널에 할당되어 있는지 확인하세요.

Next, check your Capacitor configuration. A typical setup may include a channel like this:

const config = { plugins: { CapacitorUpdater: { defaultChannel: 'production' } }
}

Capgo 대시보드를 열고 영향을 받은 장치를 검사하세요. 현재 채널, 앱 ID, 버전, 마지막 체크인 시간을 확인하세요. 기대하는 업데이트를 받은 장치의 값을 비교하면 문제를 빠르게 찾을 수 있습니다.

현재 애플리케이션 code의 로컬 오버라이드들을 찾으세요. setChannel()변경은 로컬 캐시를 변경합니다. 백엔드 디바이스 오버라이드가 생성되지 않습니다. 대시보드에서는 오버라이드가 없을 수 있지만 앱은 여전히 로컬 채널을 사용합니다.

디바이스가 정상적인 라우팅으로 돌아가야 할 때 로컬 값을 지우세요. 디바이스의 채널 할당을 제거하는 플러그인 메서드를 사용하거나 채널을 설정하는 code을 삭제하고 앱을 재설치하여 깨끗한 테스트를 수행하세요.

주요 takeaway: 변경된 Cloud Default는 더 강한 디바이스, 앱 또는 로컬 채널 할당을 대체할 수 없습니다.

2단계: 앱, 네이티브 런타임 및 업데이트 호환성 확인

설치된 앱이 업로드한 번들을 수용할 수 있는지 증명하는 것이 목표입니다. 올바른 채널은 여전히 호환되지 않은 네이티브 런타임으로 업데이트를 전달할 수 없습니다.

앱 ID부터 시작하세요. 디바이스에 설치된 앱은 업로드한 번들의 프로젝트와 동일한 앱 식별성을 사용해야 합니다. 일치하지 않으면 채널 문제처럼 보일 수 있습니다. 디바이스는 잘못된 Capgo 앱을 확인합니다.

그다음 네이티브 런타임 버전과 번들의 호환성 규칙을 비교하세요. Capgo 라이브 업데이트는 자바스크립트, CSS 및 웹 자산을 변경할 수 있지만 네이티브 플러그인을 추가하거나 네이티브 프로젝트 code을 변경할 수 없습니다. 네이티브 변경은 새로운 스토어 빌드를 필요로 합니다.

native 런타임을 웹 code의 프레임으로 생각하십시오. 새로운 번들을 설치한 경우, 기존 앱이 API을 지원하지 않는다면 Capgo은 업데이트를 적용하지 않아야 합니다..compatiable native 버전을 빌드하고 업로드한 후에 테스트해 보십시오.

설치된 앱의 버전과 플랫폼을 확인하고, 안드로이드 번들을 안드로이드에서 먼저 테스트하고, iOS 번들을 iOS에서 테스트하십시오. 또한 채널이 버전 게이트를 사용하는 경우, 번들이 올바른 앱 버전을 대상으로 하는지 확인하십시오.

변경 후defaultChannel프로젝트 루트에서 sync 명령어를 실행하십시오:

npx cap sync

이 단계는 업데이트된 설정을 native 프로젝트에 복사합니다. 동기화하지 않고 편집하면 native 앱이 이전 채널 설정을 유지합니다. stale native 프로젝트에서 새로운 빌드를 생성하면 동일한 결과를 재생산합니다.capacitor.configclean 테스트를 위해 동기화를 한 후에 새로운 앱을 빌드하십시오. 기존 바이너리가 설치된 휴대폰에 의존하지 마십시오. 캐시된 로컬 채널 상태를 삭제하려면 기존 앱을 삭제하고, 새로운 빌드를 설치한 후 채널을 다시 확인하십시오.

__CAPGO_KEEP_0__ 업데이트 동작 설명서

업데이트가 실패한 것으로 판단하기 전에, 업데이트를 확인하는 타이밍을 사용하십시오. 앱을 실행하거나 다시 전면에 띄우고, 업데이트를 확인하는 과정을 완료한 후에 결정하십시오. Capgo update behavior documentation __CAPGO_KEEP_0__ 업데이트 동작 설명서

__CAPGO_KEEP_0__

이러한 검사에 통과한 앱이 있다면, 오류의 원인을 좁힌 것입니다. 다음 질문은 릴리스가 의도한 채널에 도달했는지 여부입니다.

3단계: 배포가 기본 채널에 도달했는지 확인하기

배포 목표는 장치가 채널을 해결하는 곳에 패키지가 존재하는지 확인하는 것입니다. 하나의 채널에 패키지를 업로드하는 것은 모든 채널에서 패키지를 사용할 수 있게 하는 것은 아닙니다.

Capgo Cloud에서 채널을 열고, 활성 패키지, 버전, 배포 상태를 확인합니다. 채널 이름을 앱이 반환한 값과 비교합니다. 작은 차이점을 주의해야 합니다.production대신prod. 채널 이름은 정확히 일치해야 합니다.

CI/CD를 통해 배포하는 경우, 업로드한 패키지에 대한 명령어 출력을 확인합니다. 앱 ID와 채널이 CLI에 전달되었는지 확인합니다. pipeline은 성공적으로 업로드를 완료했지만, 실수로 스테이징 채널을 대상으로 했다면, 오류가 발생할 수 있습니다.

패키지 상태를 확인합니다. 대본 또는 비활성 릴리스는 대시보드에 표시될 수 있지만 장치에 사용할 수 없습니다. 채널이 롤아웃 중이라면, 장치가 롤아웃 규칙을 충족하지 못할 수 있습니다.

테스트 장치를 하나 사용합니다. 명확한 역할을 부여합니다. 예를 들어, 테스트 채널에 장치를 고정하고 다른 장치는 Cloud Default로 남겨둡니다. 무해한 변경을 업로드하고, 두 장치의 체크인 기록을 비교합니다. 이 방법은 테스트의 추측을 제거합니다.

Capgo의 실시간 OTA 엔진은 웹-layer 변경을 위해 설계되었습니다. JavaScript 번들, CSS 또는 자산 업데이트만 이동할 수 있습니다. 새로운 스토어 리뷰를 기다리지 않습니다. 이 속도는 기기에서 확인하는 정확한 채널에서 활성화된 릴리스에 따라 달라집니다.

만약 Cloud Default를 최근에 변경했다면 기기의 시간을 기억하세요. 새로운 설치는 새로운 경로를 즉시 사용합니다. 기존 기기는 다음 업데이트 확인을 수행할 때 일반적으로 Switch합니다. 앱을 닫고 다시 열면 확인을 트리거할 수 있지만 pinned 채널을 강제로 변경할 수는 없습니다.

Now verify the result inside the app. Call __CAPGO_KEEP_0__ after the updater starts. Log the returned channel beside the app version and bundle version. This is more useful than checking only the dashboard because it shows what the device believes.getChannel()기기가 런칭 또는 전면만 확인할 때는 지연이 발생할 수 있습니다. 테스트를 위해 항상 업데이터를 시작하는 화면을 열지 마십시오. 짧은 테스트 빌드를 위해 알려진 시작 경로에 체크를 넣고, 릴리스 전에 추가 로깅을 제거하십시오.

반환된 채널이 올바르지만 번들이 도착하지 않으면 호환성과 롤아웃 규칙으로 이동하십시오. 반환된 채널이 잘못되면 Step 1로 돌아가고 Cloud Default assignment을 삭제하십시오.

Step 4: Force a Fresh Sync and Inspect Device-Side Logs

기기의 오래된 로컬 상태와 서버 사이드 전달 문제를 분리하는 것이 목표입니다. 새로운 확인으로 새로운 증거를 얻을 수 있습니다.

__CAPGO_KEEP_0__의 실시간 OTA 엔진은 웹-layer 변경을 위해 설계되었습니다. JavaScript 번들, CSS 또는 자산 업데이트만 이동할 수 있습니다. 새로운 스토어 리뷰를 기다리지 않습니다. 이 속도는 기기에서 확인하는 정확한 채널에서 활성화된 릴리스에 따라 달라집니다.

첫 번째로, 장치가 네트워크 접근이 가능하도록 확인하세요. 앱 세션이 성공적으로 완료되더라도 업데이터가 엔드포인트에 접근할 수 있는지 확인할 수 없습니다. 기업 필터, VPN 규칙, 캡티브 게이트웨이, 또는 만료된 세션은 업데이트 요청을 차단할 수 있습니다.

다음으로 앱을 전면에 가져와 업데이터 체크를 완료하도록 기다리세요. 앱이 업데이트된 상태 이벤트를 노출한다면, 현재 채널과 함께 그 이벤트를 로깅하세요. 업데이트가 시작된다는 것만 로깅하지 마세요. 앱이 패키지를 찾았는지, 다운로드했는지, 검증했는지, 설치했는지, 또는 거부했는지 알 수 있어야 합니다.

Capgo의 장치 로그를 사용하여 첫 번째 실패한 단계를 찾으세요. 첫 번째 오류는 일반적으로 마지막 “업데이트 실패” 메시지보다 유용합니다. 예를 들어, 채널이 누락된 경우 라우팅에 문제가 있습니다. 호환성 거부는 네이티브 런타임 또는 버전 게이트에 문제가 있습니다. 다운로드 오류는 네트워크 접근 또는 패키지 요청에 문제가 있습니다.

재설치가 유용한 테스트지만 증거를 바꾸는 것입니다. 재설치를 사용하면 로컬 채널 상태를 지울 수 있습니다. 현재 채널과 로그를 캡처한 후에 사용하세요, 아니라면 이전에 사용하지 마세요.

반복 가능한 확인을 위해 다음 값을 한 줄의 로그에 기록하세요:

• 앱 ID 및 네이티브 앱 버전
• 해결된 채널에서getChannel()
• 마지막 업데이터 확인 시간
• 서버에서 찾은 번들 버전
• 설치 또는 거부 결과

그 작은 기록은 테스트자가 문제를 수동으로 재현할 수 없을 때 장치가 속한 테스터의 장치에 도움이 됩니다. 또한 CI 팀에게는 자동화된 스모크 테스트에 대한 명확한 신호를 제공합니다.

업데이터 소스 저장소인 공식 Capgo Capacitor Updater 소스 저장소를 사용하여 플러그인 API 동작을 검사할 때 필요합니다. 특히, 지역 채널 변경과 대시보드 장치 할당 간의 차이를 주의 깊게 살펴보세요.

프로 팁: 해결된 채널을 지우기 전에 캡처하세요. 그렇지 않으면 상태를 고정하고 실패를 설명한 클루를 잃을 수 있습니다.

5단계: 롤아웃 규칙, 버전 게이트, 자동 롤백 검토

Capgo이 의도적으로 업데이트를 보류하거나 반전했는지 확인하는 것이 목표입니다. 업데이트가 누락된 경우는 안전 규칙이 작동하는 것일 수 있습니다.

채널 설정을 열고 모든 릴리스에 첨부된 규칙을 검토하세요. 릴리스에 대한 최소 앱 버전, 퍼센티지 롤아웃 설정, 장치 필터, 조건을 찾으세요. 규칙에 속하지 않는 장치는 채널이 올바르더라도 현재 번들을 유지합니다.

버전 형식도 확인하세요. Capgo은 릴리스를 비교할 때 의미 있는 버전 형식을 사용합니다. 사람이 보기에는 릴리스가 보이지만 앱이나 번들을 사용하는 형식이 예상치 못한 경우에는 다른 동작을 하게 됩니다. 네이티브 빌드와 OTA 릴리스 간에 형식이 일관되게 유지하세요.

그 다음 롤백 동작을 검토하세요. 자동 롤백은 실패한 건강 검사 후 기기에서 이전 번들을 다시 설치할 수 있습니다. 기대하는 릴리스가 있지만 사용할 수 없는 상태로 남아 있는 code를 대시보드에서 볼 수 있습니다.

사용자 번들을 삭제하기 전에 이벤트를 검토하지 마세요. 삭제는 유용한 증거를 삭제합니다. 먼저 번들의 버전, 채널, 릴리스 상태, 롤백 이유를 기록하세요. 그런 다음 릴리스를 중단하거나 알려진 좋은 버전을 게시하기로 결정하세요.

위험한 변경을 위한 스테이지 채널을 사용하세요. 작은 테스트 그룹에 번들을 보내고 수용률과 오류 신호를 모니터링하세요. 릴리스가 예상대로 동작하는 경우 롤아웃을 진행하세요. 이로써 모든 활성 기기에 한 번에 나쁜 웹 레이어 변경이 도달하지 않습니다.

OTA가 변경할 수 있는 code만 롤백합니다. 실패가 네이티브 플러그인 미스가거나 호환되지 않는 네이티브 API에서 오는 경우 새로운 스토어 빌드를 필요로 합니다. 이전 자바스크립트 번들을 보내면 앱이 부족한 네이티브 부분을 추가하지 않습니다.

규칙을 검사할 때 세 가지 질문을 하세요:

• 이 기기는 앱 버전 조건을 충족합니까?
• 기기는 롤아웃 그룹 내에 있습니까?
• 건강 검사나 수동 액션으로 이전 번들을 다시 설치했습니까?

Capgo은 여기서 유용합니다. 동일한 채널 모델은 단계별 릴리스를 전달하고 롤백을 지원하며 업데이트된 활동을 하나의 워크플로우에서 보여줍니다. 규칙 세트를 작게 유지하세요. 짧은 정책은 예외가 쌓인 사고 중에 빌드되는 스택보다 ауд토를 쉽게 할 수 있습니다.

If you need API-based checks, the Capgo 공개 API 문서 는 장치, 채널 및 패키지에 대한 리소스를 설명합니다. 서버의 시점과 앱이 보고하는 내용을 비교하여 스태일한 대시보드 필터나 자동화에 의해 생성된 장치 할당을 발견할 수 있습니다.

롤백은 테스트 대체가 아닌 안전 장치입니다. 모든 운영 채널에 하나의 알려진 좋은 패키지를 유지하세요.

Step 6: Real-Time Analytics를 사용하여 정확한 실패 지점을 찾으세요

목표는 '업데이트되지 않은'을 하나의 실패로 다루지 않는 것입니다. 분석은 장치가 업데이트를 확인하지 않았는지, 적합한 패키지를 찾지 못했는지, 다운로드 중 실패했는지, 나중에 롤백했는지 등을 보여줍니다.

먼저 영향을 받은 장치 그룹에서 시작하세요. 앱 버전, 플랫폼, 채널 및 패키지 버전으로 필터링하여 패턴을 찾으세요. 만약 하나의 오래된 앱 빌드만 실패한다면, 네이티브 호환성 게이트가 문제일 수 있습니다. 만약 하나의 채널에서 모든 장치가 실패한다면, 채널 또는 배포를 검사하세요.

시간에 따른 수용률을 비교하세요. 릴리스 후 평평한 선은 라우팅 또는 적격성 문제를 나타냅니다. 상승 후 하락은 설치 오류 또는 롤백을 나타냅니다. 느리게 상승하는 선은 단순히 장치가 앱을 열지 않았을 수 있습니다.

__CAPGO_KEEP_0__의 시간표를 신중하게 사용하세요. 대시보드 이벤트 시간은 사용자의 로컬 시간과 다를 수 있습니다. 업데이트 이벤트를 장치의 마지막 체크인 시간과 일치시킵니다. 이 방법은 테스터가 앱이 실제로 체크인하기 전에 업데이트 실패했다고 말할 때 도움이 됩니다.

분석도 여러분이 채널 변경을 안전하게 테스트하는 데 도움이 됩니다. 한 번에 하나의 변수를 변경하세요. 라우팅을 변경하지 않고 버블을 테스트하세요. 그런 다음 라우팅을 변경하지 않고 새로운 버블을 테스트하세요. 두 가지를 모두 변경하면 데이터가 문제를 해결한 변경 사항을 알려주지 못합니다.

사고 시에 작은 증거 세트를 저장하세요:

• 장치 식별자 또는 내부 테스트 레이블
• 해결된 채널
• 네이티브 앱 버전
• 예상한 버블 및 설치된 버블
• 마지막 체크인 시간
• 롤백 또는 거부 이벤트

Capgo의 실시간 뷰가 가장 유용한 시점은 CI/CD를 통해 업데이트를 보내는 릴리스 프로세스 시점입니다. 배포 작업이 버블을 업로드하고, 모니터링 단계가 테스트 장치가 의도한 채널과 버블을 보고하는지 확인할 수 있습니다. 이로써 수동으로 신고하는 것을 릴리스 게이트로 바꿀 수 있습니다.

분석 데이터를 릴리스 기록과 연결하세요. 배포 노트에 커밋 또는 빌드 참조를 기록하세요. 두 버블이 유사한 버전 레이블을 가지고 있다면 빌드 참조가 실제로 이동한 code를 알려줍니다.

기존 장치만 업데이트 후 Cloud Default 변경 후에 실패한다면, 더 많은 설정을 변경하기 전에 다음 체크인까지 기다리세요. 새로운 설치는 유용한 컨트롤입니다. 기존 로컬 상태가 없는 장치에 대한 기본 루트가 작동하는지 알려줍니다.

7단계: 기본 채널이陈舊되지 않도록 방지하기

사용자에게 영향을 미치기 전에 채널 드리프트를 표시하는 것을 목표로 합니다. 작은 릴리스 체크리스트는 반복되는 대부분의 경우를 방지할 수 있습니다.

각 앱 환경에 하나의 라우팅 모델을 선택하세요. 프로덕션에서, __CAPGO_KEEP_0__ Cloud가 기본 채널을 제어할 수 있도록 생략할 수 있습니다. 테스트 빌드에서, 명시적인 채널을 설정할 수 있습니다. 위험한 설정은 오래된 로컬 오버라이드,陈舊된 네이티브 구성, 그리고 nobody가 검증하지 않은 Cloud 기본 채널의 혼합입니다.defaultChanneland let Capgo Cloud control the default. For a test build, you may set an explicit channel. The dangerous setup is a mix of old local overrides, stale native config, and a new Cloud Default that nobody verifies.

빌드가 실패할 경우 동기화 단계가 실패한 경우를 확인하세요. 명령은 간단하지만 생략하면昨天의 채널이오늘의 네이티브 바이너리에 구워질 수 있습니다.npx cap sync배포 후 스모크 테스트를 추가하세요. 테스트 디바이스는 앱을 실행하고

를 호출하고 기대하는 번들을 확인하고 결과를 기록하세요. 검증은 OTA 워크플로우에서 종종 누락된 단계입니다. 업로드만 하면 매우 적은 것을 증명할 수 있습니다.getChannel()로컬 채널 __CAPGO_KEEP_0__을 명확한 기능 플래그 뒤에 유지하세요. 테스트 헬퍼가

Keep local channel code behind a clear feature flag. If a test helper callssetChannel()릴리스 체크리스트를 사용하세요:

앱 ID와 네이티브 버전을 확인하세요.

1. 7단계: 기본 채널이陈舊되지 않도록 방지하기
2. __CAPGO_KEEP_0__은 조직당 구독을 사용하며 14일 무료试用이 있습니다. 试用 기간을 앱 빌드에 실제 릴리스 흐름을 테스트하는 기회로 간주하고, 대시보드만 검사하기 위해 사용하지 마십시오. 1개의 스테이징 배포, 1개의 롤백 테스트, 1개의 자동 채널 확인을 시도하십시오.
3. __CAPGO_KEEP_0__은 CI/CD 토큰을 보호하고, Cloud Default 변경을 제한하고, 로컬 스크립트에서 프로덕션 배포 자격 증명을 제거하는 것을 포함하여 보안을 동일한 체크리스트에 포함하십시오. 비인가된 채널 변경은 audit 트레일을 검토할 때까지陈舊한 장치로 보일 수 있습니다.
4. __CAPGO_KEEP_0__은 자주 배포하는 팀에게 프로세스를 재미없게 유지하십시오. 1개의 배포 명령, 1개의 알려진 테스트 장치, 1개의 명확한 채널 규칙. 추적, 채택, 롤백.
5. __CAPGO_KEEP_0__은 __CAPGO_KEEP_0__을 사용하여 __CAPGO_KEEP_0__을 __CAPGO_KEEP_0__합니다.
6. __CAPGO_KEEP_0__은 __CAPGO_KEEP_0__을 __CAPGO_KEEP_0__합니다.getChannel().
7. __CAPGO_KEEP_0__은 __CAPGO_KEEP_0__을 __CAPGO_KEEP_0__합니다.

__CAPGO_KEEP_0__은 __CAPGO_KEEP_0__을 __CAPGO_KEEP_0__합니다.

Capgo은 Capgo을 Capgo합니다.

__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__은 __CAPGO_KEEP_0__을 __CAPGO_KEEP_0__합니다.

FAQ

왜 Capgo 클라우드 기본 채널이 기존 장치에 업데이트를 적용하지 않는가?

기존 장치는 다음 업데이트를 확인할 때까지 이전 채널을 유지할 수 있다. 지역 채널, 대시보드 오버라이드 또는 강제 할당이 클라우드 기본 채널보다 우선순위를 가질 수도 있다. 장치의 해결된 채널을 확인하고 강한 할당을 취소한 후 앱을 전면에 띄운다.getChannel()클라우드 기본을 변경하면 모든 설치된 앱을 변경하는가?

Does changing the Capgo Cloud Default change every installed app?

npx cap sync가 __CAPGO_KEEP_0__ 채널 변경에 대해 무엇을 수행하는가?

Capgo 채널 변경을 위해 업데이트된 Capgo 구성이 네이티브 프로젝트에 복사된다. 변경을 생략하고 sync를 생략하면 다음 네이티브 빌드는 이전 채널 설정을 포함할 수 있다. 프로젝트 루트에서 명령어를 실행하고, 빌드하고, 새 테스트 바이너리를 설치한다.

npx cap syncsetChannel은 Capacitor에서 장치 오버라이드를 생성하는가?defaultChannel아니요,

Capgo 채널을 변경하면 장치의 채널을 저장한다. 이는 백엔드 장치 오버라이드가 생성되지 않으므로 Capgo 대시보드에서는 장치가 오버라이드되지 않은 것으로 표시될 수 있다. 장치가 기본 라우팅으로 돌아가야 하는 경우 지역 할당을 취소하고 결과를 확인한다.

__CAPGO_KEEP_0__setChannel()CapgogetChannel().

Capgo은 code을 OTA 배포를 통해 업데이트할 수 있나요?

Capgo은 웹-layer code인 자바스크립트, CSS 및 자산에 OTA 업데이트를 적용합니다. 네이티브 플러그인, 권한 또는 네이티브 API 변경은 새로운 스토어 빌드를 필요로 합니다. 만약 배포가 설치된 앱이 부족한 네이티브 code을 기대한다면, 채널이 올바르더라도 업데이트가 거부될 수 있습니다.

결론

첫 번째 단계는 채널을 해결한 채로 시작하는 것입니다. assignments를 확인하고, run을 실행하고, 배포를 네이티브 런타임과 확인하고, 장치 로그를 검사하기 전에 배포 규칙을 변경하지 마십시오. 그 다음 __CAPGO_KEEP_0__에서 작은 post-deploy 테스트를 추가하여 npx cap sync, verify the bundle against the native runtime, and inspect the device logs before changing rollout rules. Then add a small post-deploy test in Capgo that callsgetChannel()마틴 도나디우