Capgo 기본 채널이 장치 업데이트를 수행하지 않습니다.

__CAPGO_KEEP_0__ 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__
• 7단계: 기본 채널이陈舊되지 않도록 방지하기
• FAQ
• 결론

1단계: 장치가 기본 채널에 할당되어 있는지 확인하기

목표는 현재 장치 채널을 결정하는 규칙을 찾는 것입니다. Cloud Default는 이미 장치가 할당된 강력한 assignment이 없을 때만 적용됩니다.

Capgo 대시보드를 열고 영향을 받은 장치를 검사합니다. 현재 채널, 앱 ID, 버전, 마지막 체크인 시간을 확인하고, 기대되는 업데이트를 받은 장치와의 비교를 통해 이슈를 швидко 식별합니다.

채널 선택은 순서에 따라 결정됩니다. 강제 채널은 우선순위가 가장 높습니다. 대시보드 또는 API 장치 오버라이드는 그다음입니다. 앱이 설정한 지역 채널이 그다음이며, Capgo이 native 앱 구성에서 확인합니다. Cloud Default는 기본값입니다.defaultChannel원래 앱 설정에서. Cloud 기본은 기본값입니다.

__CAPGO_KEEP_0__ 업데이터 디버깅 가이드를 사용하세요.

Capgo Capgo 업데이터 디버깅 가이드를 사용하세요. __CAPGO_KEEP_0__ 업데이터 디버깅 가이드를 사용하세요.

다음으로, Capacitor 설정을 확인하세요. 일반적인 설정에는 다음과 같은 채널이 포함될 수 있습니다:

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

이 필드는 선택 사항입니다. 채널을 생략하면 장치가 Cloud Default를 상속할 수 있습니다. 이는 프로덕션 빌드에 적합할 수 있습니다. 채널 라우팅은 Capgo Cloud에서 유지되기 때문입니다. 채널을 포함하려면 실제로 배포하는 채널과 일치하는 값을 지정해야 합니다.

현재 애플리케이션 code의 로컬 오버라이드 값을 찾으세요. 다음 함수 호출을 확인하세요:setChannel()로컬 캐시를 변경합니다. 백엔드 장치 오버라이드가 생성되지 않습니다. 따라서 대시보드에서는 오버라이드가 표시되지 않지만 앱은 로컬 채널을 계속 사용합니다.

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

중요한 점: 변경된 Cloud Default는 더 강한 장치, 앱 또는 로컬 채널 할당을 대체할 수 없습니다.

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

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

앱 ID부터 시작하세요. 장치에 설치된 앱은 프로젝트에서 업로드한 번들과 동일한 앱 식별자를 사용해야 합니다. 식별자가 일치하지 않으면 채널 문제처럼 보일 수 있습니다. 장치가 잘못된 Capgo 앱을 확인하기 때문입니다.

그런 다음 원시 런타임 버전을 패키지의 호환성 규칙과 비교하십시오. Capgo Live Update는 JavaScript, CSS 및 웹 자산을 변경할 수 있지만 원시 플러그인을 추가하거나 원시 프로젝트 code를 변경할 수 없습니다. 원시 변경은 새로운 스토어 빌드를 필요로 합니다.

원시 런타임을 웹 code 주변의 프레임으로 생각하십시오. 새로운 패키지가 설치된 앱이 가지고 있지 않은 원시 API을 기대한다면 Capgo를 적용하지 않아야 합니다. 호환되는 원시 버전을 빌드하고 업로드한 후 패키지를 테스트하십시오.

설치된 앱의 버전과 플랫폼을 확인하고 Android 패키지를 Android에서 먼저 테스트하고 iOS 패키지를 iOS에서 테스트하십시오. 또한 채널이 버전 게이트를 사용할 때 패키지가 올바른 앱 버전을 대상으로 하는지 확인하십시오.

변경 후defaultChannel프로젝트 루트에서 sync 명령어를 실행하세요.

npx cap sync

이 단계에서는 업데이트된 구성이 네이티브 프로젝트로 복사됩니다. 편집capacitor.configwithout syncing leaves the native app on its old channel setting. A fresh build from that stale native project will keep reproducing the same result.

For a clean test, build a new app after syncing. Do not rely on an old binary installed on your phone. Uninstall it when you need to remove cached local channel state, then install the new build and check the channel again.

The Live Update Capgo 업데이트 동작 설명서 __CAPGO_KEEP_0__ 업데이트 동작 설명서

또한 번들의 네이티브 버전 게이트도 확인해 보세요. 번들이 올바른 채널에 존재해도, 장치의 최소 앱 버전이 번들의 버전과 맞지 않으면 사용할 수 없습니다. 릴리스 상세 정보는 대시보드에서 확인하세요. 최신 업로드가 모든 설치에 적용되는 것으로 가정하지 마세요.

앱이 이러한 확인을 통과하면, 문제를 좁힌 것입니다. 다음 질문은 릴리스가 의도한 채널에 도달했는지 여부입니다.

Step 3: Default 채널에 배포가 실제로 도달했는지 확인하기

컨텍스트: Capgo 페이지에 관한 정보. 역할: UI 레이블. 위치: about.astro 페이지에 나타남. 메시지 키 `about_how_step_label` (About How Step Label).

Open the channel in Capgo Cloud. Check the active bundle, its version, and its deployment state. Compare the channel name with the value returned by the app. Watch for small differences such asproductionversusprod예를 들어

If you deploy through CI/CD, inspect the command output from the same job that uploaded the bundle. Confirm the app ID and channel passed to the CLI. A pipeline can finish with a successful upload while targeting a staging channel by mistake.

CI/CD를 통해 배포하는 경우, 업로드한 번들의 명령어 출력을 확인하세요. 앱 ID와 채널을 확인하세요. pipeline이 성공적으로 업로드를 완료했더라도, 스테이징 채널을 의도적으로 업로드한 경우가 있습니다.

1개의 테스트 장치를 사용하세요. 그 장치에 명확한 역할을 부여하세요. 예를 들어, 하나의 장치를 테스트 채널에 고정하고 다른 장치를 Cloud Default로 남겨두세요. 무해한 변경을 업로드한 후, 그들의 체크인 기록을 비교하세요. 이로 인해 테스트에서 추측이 사라집니다.

Capgo의 OTA 엔진은 웹-layer 변경을 위해 설계되었습니다. JavaScript 번들, CSS, 또는 자산 업데이트만 이동할 수 있습니다. 새로운 스토어 리뷰를 기다리지 않습니다. 이 속도는 장치가 정확한 채널에서 체크하는 경우에만 적용됩니다.

Cloud Default를 몇 초 전에 변경한 경우 장치의 시간을 기억하세요. 새로운 설치는 새로운 경로를 즉시 사용합니다. 기존 장치는 다음 업데이트를 체크할 때 일반적으로 Switch합니다. 앱을 닫고 다시 열면 업데이트를 트리거할 수 있지만 pinned 채널을 강제로 변경할 수는 없습니다.

현재 결과를 앱 내에서 확인하세요. 호출getChannel()만약 앱이 런칭 또는 전면에서만 체크한다면, 지연이 발생할 수 있습니다. 항상 업데이터가 시작되는 화면을 열지 마세요. 짧은 테스트 빌드를 위해 알려진 시작 경로에 체크를 추가한 후, 릴리스 전에 추가 로깅을 제거하세요.

만약 반환된 채널이 정확하지만 번들이 도착하지 않는다면, 호환성과 롤아웃 규칙으로 이동하세요. 만약 반환된 채널이 잘못되었다면, Step 1로 돌아가서 Cloud Default가 이길 때 assignment을 삭제하세요.

4단계: 강제로 최신화하고 장치측 로그를 검사하세요.

Step 4: 새로고침하고 장치 내 로그를 확인하십시오

새로운 목표는 지역 상태와 서버 측 배포 문제를 분리하는 것입니다. 최신 체크인으로 새로운 증거를 얻을 수 있습니다.

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

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

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

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

위치가 반복적으로 체크되려면 다음 값을 한 줄의 로그에 기록하세요:

• 앱 ID와 네이티브 앱 버전
• 해당되는 채널getChannel()
• 업데이터가 마지막으로 체크한 시간
• 서버에서 찾은 번들 버전
• 설치 또는 거부 결과

이 작은 기록은 테스터가 문제를 즉시 재현할 수 없는 장치에 속하는 경우 문제를 해결하는 데 도움이 됩니다. 또한 CI 팀에게 자동화된 스모크 테스트를 위한 명확한 신호를 제공합니다.

공식 Capgo Capacitor 업데이터 소스 저장소 사용을 고려하세요. 이 저장소에서 플러그인 API 동작을 검사할 수 있습니다. 특히, 로컬 채널 변경과 대시보드 장치 할당 간의 차이를 주의하세요.

프로 팁: 해당되는 채널을 기록하세요. 채널을 지우면 상태를 고정하고 실패를 설명한 클루를 잃을 수 있습니다.

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

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

__CAPGO_KEEP_0__ 채널 설정을 열고 모든 릴리스에 첨부된 규칙을 검토하십시오. 릴리스에 대한 최소 앱 버전, 퍼센티지 롤아웃 설정, 장치 필터, 릴리스에 대한 조건을 찾으십시오. 규칙에 속하지 않는 장치는 채널이 올바르더라도 현재 배포본에 머물러 있습니다.

버전 형식도 확인하십시오. Capgo은 릴리스를 비교할 때 의미 있는 버전 형식을 사용합니다. 사람이 보기에는 버전 게이트가 올바르지만 앱이나 배포본이 예상치 못한 형식을 사용하는 경우에는 다른 방식으로 동작할 수 있습니다. 네이티브 빌드와 OTA 릴리스 간에 형식이 일관되도록 하십시오.

Then review rollback behavior. An automatic rollback may move a device back to a prior bundle after a failed health check. The dashboard can show the older active code while the release you expect remains present but unavailable.

사용자 배포본을 삭제하기 전에 이벤트를 검토하지 마십시오. 삭제는 유용한 증거를 삭제합니다. 먼저 배포본 버전, 채널, 롤아웃 상태, 롤백 이유를 기록하십시오. 그런 다음 릴리스를 중단하거나 알려진 좋은 버전을 게시하십시오.

위험한 변경을 적용할 때는 스테이지 채널을 사용하십시오. 작은 테스트 그룹에 배포본을 먼저 보내십시오. 수용률과 오류 신호를 모니터링하십시오. 릴리스가 예상대로 동작할 때까지 롤아웃을 진행하십시오. 이렇게 하면 모든 활성 장치에 한번에 나쁜 웹 레이어 변경이 퍼지지 않습니다.

code만 OTA가 변경할 수 있는 부분만 롤백합니다. OTA가 변경할 수 없는 native 플러그인 또는 native API의 호환성 문제로 인한 실패는 새로운 스토어 빌드를 필요로 합니다. 이전 JavaScript 번들을 보내더라도 앱이 부족한 native 부분을 추가하지 않습니다.

규칙을 검사할 때 세 가지 질문을 합니다:

• 이 기기는 앱 버전 조건을 충족합니까?
• 이 기기는 롤아웃 그룹 내에 있습니까?
• 건강 검사 또는 수동 작업으로 기기가 이전 버전으로 돌아간 경우?

Capgo은 같은 채널 모델이 단계별 릴리즈를 지원하고 롤백을 지원하며 업데이트 활동을 표시할 수 있기 때문에 유용합니다. 규칙 세트를 작게 유지하세요. 짧은 정책은 예외 처리를 통해 발생한 사고를 감사하는 것이 더 쉽습니다.

API-기반 체크가 필요하다면 Capgo 공개 API 문서 기기, 채널 및 번들의 리소스에 대한 설명을 포함합니다. 서버의 시각과 앱이 보고하는 시각을 비교하여 스태일된 대시보드 필터 또는 자동화에 의해 생성된 기기 할당을 발견할 수 있습니다.

롤백은 테스트 대체가 아닌 안전 장치입니다. 모든 프로덕션 채널에 하나의 알려진 좋은 번들을 유지하세요.

Step 6: Capgo에서 실시간 분석을 사용하여 정확한 실패 지점을 찾으세요.

업데이트되지 않은 장치가 하나의 실패로 간주되지 않도록 하려는 목표입니다. 분석은 장치가 업데이트를 확인하지 않았는지, 업데이트할 수 있는 패키지를 찾지 못했는지, 다운로드 중 실패했는지, 나중에 롤백했는지 등을 보여줍니다.

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

시간에 따른 채택률을 비교하세요. 출시 후 평평한 선이 나타나면 라우팅 또는 승인 문제가 있습니다. 상승 후 하락이 나타나면 설치 오류 또는 롤백이 있습니다. 천천히 상승하는 선은 단순히 장치가 앱을 아직 열지 않았을 수 있습니다.

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

분석은 채널 변경을 안전하게 테스트하는 데 도움이 됩니다. 하나의 변수를 변경할 때마다 다른 변수를 변경하지 마세요. 라우팅을 테스트할 때 패키지를 일정하게 유지하고, 패키지를 테스트할 때 라우팅을 일정하게 유지하세요. 두 변수를 모두 변경하면 데이터가 문제를 해결한 변경 사항을 알려주지 못합니다.

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

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

Capgo의 실시간 뷰어는 CI/CD 프로세스에서 업데이트를 전송할 때 가장 유용합니다. 배포 작업은 패키지를 업로드하고, 모니터링 단계는 테스트 장치가 의도한 채널과 패키지를 보고하는지 확인합니다. 이로 인해 수동으로 신고하는 것을 릴리스 게이트로 바꿉니다.

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

기존 장치만 Cloud Default 변경 후 실패하는 경우, 더 많은 설정을 변경하기 전에 다음 체크인까지 기다려보세요. 새로운 설치는 장치가 이전에 로컬 상태를 가지고 있지 않은 경우 기본 루트가 작동하는지 알려줍니다.

7. 기본 채널이陈舊해지지 않도록 방지하세요

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

환경에 맞는 라우팅 모델을 하나씩 선택하세요. 운영 환경에서는 생략할 수 있습니다.defaultChannelCapgo Cloud가 기본을 제어하는 것을 생략할 수 있습니다.

Putnpx cap sync배포 경로에

를 추가하세요. 빌드가 실패하는지 확인하세요. sync 단계가 실패하는 경우 빌드가 실패해야 합니다. 명령은 간단하지만 생략하는 경우 오늘날의 네이티브 바이너리에昨天의 채널을 구워버리게 됩니다.getChannel()업로드만으로는 충분하지 않습니다. OTA 워크플로우에서 종종 누락되는 확인 단계입니다.

로컬 채널 code을 명확한 기능 플래그로 유지하세요. 테스트 헬퍼가 호출하는 경우setChannel()생산 빌드에 의해 우발적으로 포함되지 않도록 하세요. 로컬 캐시가 대시보드 오버라이드로 나타나지 않을 수 있으므로 UI가 모든 문제를 잡아내지 못할 수 있습니다.

다음과 같은 릴리스 체크리스트를 사용하세요:

1. 앱 ID와 네이티브 버전을 확인하세요.
2. 대상 채널을 선택하세요.
3. 채널에 업로드한 번들을 확인하세요.
4. 번들이 활성화되었는지 확인하세요.
5. 디바이스 스모크 테스트를 실행하세요.
6. 반환된 채널과 함께getChannel().
7. 확산을 넓히기 전에 채널의 채택을 확인하세요.

생산 릴리스에 롤백 보호를 유지하세요. 채널이나 롤백 계획이 명확하지 않은 채로 배포하는 것은 팀이 나쁜 번들을 중단하는 안전한 방법이 적어지는 일반적인 실패 패턴입니다.

Capgo은 조직당 구독을 사용하며 14일 무료试用 기간이 있습니다. 试用 기간을 앱 빌드에 실제 릴리스 흐름을 테스트하는 기회로 간주하고, 단일 스테이징 배포, 롤백 테스트, 자동 채널 확인만으로는 충분하지 않습니다.

보안은 동일한 체크리스트에 속합니다. CI/CD 토큰을 보호하고, Cloud Default 변경을 제한하고, 로컬 스크립트에서 프로덕션 배포 자격 증명을 제외합니다. 비인가된 채널 변경은 인증 트레일을 검토할 때까지 기존 장치가 보이는 것처럼 보일 수 있습니다.

자주 배포하는 팀은 프로세스를 재미없게 유지하세요. 배포를 위한 단일 명령, 알려진 테스트 장치, 명확한 채널 규칙. 추적, 채택, 롤백.

주요 takeaway: 기존 라우팅을 방지하기 위해 config를 동기화하고, 숨겨진 로컬 오버라이드를 피하고, 해결된 채널을 테스트하고, 롤백 준비를 유지하세요.

FAQ

Why is the Capgo cloud default channel not updating existing devices?

__CAPGO_KEEP_0__ 클라우드 기본 채널이 기존 장치에 업데이트되지 않는 이유는 무엇인가요?getChannel()앱을 전면에 띄우고 강한 할당을 취소하세요.

클라우드 기본 Capgo을 변경하면 모든 설치된 앱이 변경되나요?

No, Cloud Default를 변경하면 모든 설치 앱의 채널이 즉시 재작성되지 않습니다. 새로운 장치에서는 새로운 기본값을 즉시 사용할 수 있지만 기존 설치는 확인을 해야만 채널을 변경할 수 있습니다. 또한 더 강한 채널 규칙이나 로컬 오버라이드가 적용되는 경우에는 채널을 변경하지 않습니다.

npx cap sync는 Capgo 채널 변경 시 어떤 일을 하는가요?

npx cap sync업데이트된 Capacitor 설정을 네이티브 프로젝트에 복사합니다. 변경한 경우defaultChannel__CAPGO_KEEP_0__에서 setChannel은 장치 오버라이드를 생성합니까?

Capgo에 장치 오버라이드가 생성되는지 setChannel이 생성하는지 궁금합니다.

No,setChannel()Capgo는 네이티브 __CAPGO_KEEP_1__를 OTA 배포를 통해 업데이트할 수 있나요?getChannel().

Capgo은 code을 OTA 패키지로 업데이트할 수 있나요?

No, Capgo OTA updates apply to web-layer code such as JavaScript, CSS, and assets. A native plugin, permission, or native API change needs a new store build. If the bundle expects native code that the installed app lacks, the update may be rejected even when the channel is correct.

Conclusion

__CAPGO_KEEP_0__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()그리고 기대하는 패키지를 확인합니다.