자바스크립트 앱을 위한 2026년 앱 헬스 체크 플레이북

금요일 오후 자바스크립트 업데이트 일정이 진행되었습니다. 앱이 열렸고, 인증이 정상이었으며, 충돌 카운터도 특별한 것은 아니었습니다. 그러나 체크아웃이 일부 기기에서 실패하기 시작했고, 앱 스토어 및 플레이 콘솔 대시보드는 롤백 결정에 자신감을 주는 정도의 정보를 제공하지 못했습니다.

앱 헬스 체크가 없이는 앱 헬스 체크 대시보드 리뷰로. 건강한 릴리스는 단지 충돌하지 않는 것만이 아니다. 빠르게 시작해야 하며, 중요한 화면을 렌더링해야 하며, 중요 journey를 완료해야 하며, 올바른 백엔드 버전을 달성해야 하며, 지연된 스토어 데이터가 따라잡기 전에 on-call 엔지니어가 행동할 수 있는 충분한 테레미트를 제공해야 한다.

내용목록

• 금요일 오후 사건이 이 플레이북을 시작하는 이유
• 사용자 고통을 예측하는 건강 기준 정의
  • 릴리스 게이트와 진단 신호를 분리
• 이번 주에 연결할 수 있는 런타임 체크
  • 결정에 영향을 미치는 신호부터 시작
  • 알람만 아니라 동작을 인스트루먼트
• 사용자가 먼저 문제를 겪기 전에 문제를 잡는 CI 체크와 헬스 엔드포인트
  • 반응이 유용하고 제한된 것만큼
  • 체크를 릴리스 경로 내에 넣기
• 업데이트, 업데이터, 그리고 스토어와 기기 사이의盲点
  • 채널을 안전한 경계로 다루세요
• 자바스크립트 앱의 보안, 권한, 및 수집기 위생
• 건강 신호가 트리플 때 Remediation 및 Rollback

금요일 오후 사건이 이 플레이북을 시작합니다

첫 번째 보고서가 일반적으로 모호한 다음과 같은 내용입니다: "체크아웃이 일부 사용자에게 깨졌습니다." 지원 팀은 몇 장의 스크린샷을 가지고 있고, 엔지니어 팀은 최근 배포본을 가지고 있으며, 스토어 콘솔에서는 명백한 백서가 없습니다. 팀은 로그를 비교하고, 하나의 기기에서 흐름을 재현하고, 업데이트 상태, 백엔드 응답 형태, 및 더 오래된 네이티브 셸에 의존하는 결함을 발견합니다.

그것은 디버깅 세션이 아닙니다. 그것은 릴리스 시스템의 실패입니다.

대부분의 KPIs에 대해 24시간, 그리고 충돌 및 ANR율에 대해 72시간 정도 지연됩니다. 스토어 수집기 지연 참조에 따르면.그것들은 추세 분석에 유용하지만, 실시간 사고 중에만 rollback 트리거로 사용할 수 없습니다.

실용적인 규칙: 스토어 콘솔은 보고 지연 후에 무슨 일이 일어났는지 알려줍니다. 업데이터와 런타임 수집기는 현재 릴리스가 현재 무엇을 하는지 알려줘야 합니다.

이러한 반복적인 건강 검사는 팀에게 세 가지 증거 층을 제공합니다:

• 런타임 품질: crashes, ANRs, 시작 동작, 화면 렌더링, 오류 및 자원 압박.
• 사용자 결과: 로그인 완료, 체크아웃 성공, 결제 확인 및 사용자가 성공 또는 실패로 인식하는 다른 여행.
• 릴리스 전달: 수용, 실패한 설치, 차단된 장치, 채널 동작 및 롤백 상태.

각 층은 해당 운영적 레버에 해당합니다. 충돌 회귀는 롤아웃을 중단하거나 자바스크립트 번들을 되돌려야 할 수 있습니다. 실패하는 백엔드 의존성은 앱 롤백이 아닌 서비스 개선이 필요합니다. 깨진 업데이트 경로는 채널 제어와 장치 수준의 조사 필요합니다.

실제 반응은 시간표에 시작해야 합니다. 배포된 번들의 날짜, 받은 채널, 첫 번째 실패한 여행의 날짜 및 영향을 받은 버전을 기록해야 합니다. 그런 다음 모바일 팀의 사고 대응 지침을 사용하여 소유주를 assign하고 증거를 보존하고 가장 안전한 액션은 채널 중단, 롤백 또는 네이티브 릴리스인지 결정해야 합니다. 이 프로세스의 목적은 간단합니다: 이 프로세스는 팀이 앱의 건강을 유지하고 사용자 경험을 최적화하는 데 도움이 됩니다.

사고 대응 지침을 사용하여 소유주를 assign하고 증거를 보존하고 가장 안전한 액션은 채널 중단, 롤백 또는 네이티브 릴리스인지 결정해야 합니다. silent failure를 줄이고 불량 신호와 안전한 동작 사이의 거리를 줄이세요.그 나머지 건강 체크는 그 결과에 따라 설계되어야 합니다.

사용자 고통을 예측하는 건강 기준 정의하기

금요일에 릴리즈를 하면 스토어 대시보드가 초록색으로 나타날 수 있지만 사용자가 로그인, 체크아웃, 업데이트 받을 수 없을 수 있습니다. '건강한' 상태를 정의하세요. 그 상태는 릴리즈, CI, 롤백 결정과 연결되어야 합니다. 스토리지 텐시메트리도 24시간에서 72시간의 블라인드 스팟이 있습니다. 그래서 디바이스 사이드 이벤트는 플랫폼이 신뢰할 수 있는 보고가 나오기 전에 해당 기간을 커버해야 합니다.

첫 번째 계층은 사용자가 의미 있는 작업을 완료할 수 있는지 여부를 설명합니다:

1. 오류 없이 세션을 유지하세요. iOS는 약 99.93%, Android는 약 99.81%로 문서화된 앱 건강 프레임워크 참조 이 값을 검토 기준으로 사용하세요. UNIVERSAL 보장은 아닙니다. 릴리즈, 운영 체제, 디바이스 패밀리, 롤아웃 코호트에 따라 구분하세요. 릴리즈에 특정한 드롭이 발생하면 확장 중단이나 번들 리버트를 트리거해야 합니다. ANR 동작behavior
2. behavior UI가 동결되면 로그인, 결제, 또는 확인이 실패할 수 있습니다. 버전과 흐름을 기준으로 ANR을 그룹화하고 WebView 작업, 플러그인 호출, 네이티브 브리지를 확인하여 메인 스레드가 차단되는지 확인합니다. 해결책은 code 또는 CI에서 오류를 수정할 수 있습니다. 배포를 중단하는 롤아웃 스위치는 일시 중단입니다.
3. 시작 및 화면 준비. UI가 즉시 반응하는지 측정하세요. 프로세스 시작 시간만 측정하는 것은 아닙니다. 빠르게 열리는 셸이 첫 번째 유용한 화면이 비어 있는 경우 여전히 불건강합니다. CI에서 회귀를 감지하는 임계값을 설정하고 실패 시 장치 로그를 검사하세요.
4. 중요한 여행 성공. 로그인, 검색, 결제, 동기화, 로그아웃은 명시적인 성공 이벤트가 필요합니다. HTTP 응답만으로는 사용자가 확인에 도달했는지 증명할 수 없습니다. 롤백을 선택하기 전에 영향을 받은 흐름을 식별해야 합니다.

배포 게이트와 진단 신호를 분리하세요.

배포 게이트 일반적으로 무사한 세션, ANR, 시작, 인증, 그리고 가장 가치 있는 사용자 여행이 포함됩니다. 진단 신호 메모리 압박, 배터리 영향, 저장 공간 증가, 네트워크 지연, HTTP 오류 클래스, WebView 렌더링이 포함됩니다. 실패를 설명하고 치료를 안내하지만 자동으로 배포를 차단하지는 않습니다.

각 기준에 네 개의 field를 작성하세요.

이것을 사용하세요 앱 헬스 모니터링 지침 시작점으로 사용하고, 모든 신호를 사람이나 회전으로 assign하고, 결과를 바꾸는 레버를 문서화하세요. raw 신호를 보이도록 유지하세요. 단일 점수는 건강한 배경 활동 뒤에 심각한 결제 실패를 숨길 수 있습니다.

건강한 릴리즈는 안정적이고 반응적이며 관찰 가능하며 사용자가 가치 있다고 여기는 작업을 완료할 수 있습니다. 또한 on-call 엔지니어가 취할 수 있는 동작과 연결되어 있습니다.

Runtime Checks You Can Wire Up This Week

사용자가 작업을 경험하는 곳에서만 앱을 인스트루먼트하세요. 단지 프로세스가 생명체라고 보고하는 곳만이 아닙니다. Capacitor 앱은 자바스크립트 예외, 네이티브 충돌, 브리지를 실패, 네비게이션 타이밍, 여행 이벤트를 캡처할 수 있습니다. Electron 앱은 렌더러 프로세스 실패, 메인 프로세스 오류, 프리로드 실패, 윈도우 준비, 리소스 관찰을 추가할 수 있습니다.

실용적인 앱 헬스 체크는 안정성과 성능을 함께 측정합니다.포함하여 충돌률, ANR률, 런칭 시간, 화면 렌더링 시간, 오류률, 리소스 활용률입니다. 또한 모바일 성능 헬스 체크 지침 릴리즈 버전과 롤아웃 코호트에 따라 구분합니다. 그 구분이 없으면 건강한 오래된 버전은 실패하는 새로운 버전을 숨길 수 있습니다.

결정에 영향을 주는 신호부터 시작하세요.

세션 식별자, 앱 버전, 네이티브 셸 버전, 플랫폼, 디바이스 클래스, 지역, 롤아웃 채널과 함께 모든 헬스 이벤트를 캡처하세요. 개인 데이터를 넣지 마세요. 컨텍스트는 on-call 엔지니어가 디버거를 열기 전에 “누구에게 영향을 미치는가?”라고 대답할 수 있도록 해줍니다.

각 신호에 대해, 목표와 응답을 정의하세요:

• Crashes: 플랫폼 벤치마크 상에 비교한 무사한 세션과 비교하세요. 릴리스별로 감소하는 경우, 영향을 받은 그룹을 잠시 중단하고, 엔지니어들이 스택 또는 플러그인 경계를 식별할 때까지 기다려보세요.
• ANRs: 화면과 작업을 기준으로 이벤트를 그룹화하세요. 브리지 호출 중 반복적인 멈춤은 데이터베이스 마이그레이션 중 멈춤과 다른 치료를 필요로 합니다.
• Launch time: 첫 번째 사용 가능한 화면이 표시되는 지점을 표시하세요. 느린 결과는 oversized 웹 자산, 동기식 초기화, 인증 확인, 또는 네비게이션 전에 실행되는 플러그인이 원인일 수 있습니다.
• Screen rendering: 체크아웃, 로그인, 검색, 기타 고가치 화면에 대해 시작 및 준비 이벤트를.emit하세요. 준비 이벤트가 누락된 경우, silent 실패를 감지할 수 있습니다. 이는 리포팅되지 않는 실패입니다.
• Error rate: 정규화된 오류 클래스, 상태 패밀리, 작업 이름을 기록하세요. 토큰, 결제 정보, 또는 전체 요청 본문을 로깅하지 마세요.
• Resource utilization: 메모리, 저장소, 배터리 동작 및 네트워크 오류를 감시하여 증거로 사용합니다. 리소스 트렌드가 실패한 여행 또는 ANR와 연관이 있을 때 가장 중요합니다.

아래 표는 의도적으로 보수적입니다. 브리프에서 벤치마크가 제공되는 경우에는 포함됩니다. 다른 밴드는 자체 기준선에서 선택하여 UNIVERSAL LIMITS로 인위적으로 만들지 않도록 합니다.

작업을 아니라 경보만 아니라 알람을 위한 동작을 측정

오류 이벤트는 릴리스와 롤백 경로를 연결해야 한다. 체크아웃 실패는 실패한 단계와 응답 클래스를 연결해야 한다. 런치 리그レ션은 초기화 단계가 시간을 소비한 단계를 연결해야 한다.

Capacitor 팀에게는 자바스크립트와 네이티브 경계 근처에서 측정 장치를 유지하고 물리적 장치에서 검증하는 것이 좋다. Electron의 경우 렌더러와 메인 프로세스 컨텍스트를 별도로 수집해야 한다. 하나의 프로세스가 실패할 수 있지만 다른 프로세스는 건강해 보일 수 있다. Capacitor 성능 모니터링 설정 릴리스 단위의 조사에 연결된 신호를 연결할 수 있는 팀에게는 이 설정이 도움이 될 수 있다.

건전함 지점 및 CI 검사 문제를 사용자보다 먼저 잡아내는

A 실행 중인 프로세스는 애플리케이션이 준비된다는 증거가 아니다. 백엔드가 TCP 연결을 수락할 수 있는 동안 데이터베이스 풀은 고갈되었을 수 있고 캐시는 사용할 수 없거나 외부 서비스가 시간 초과될 수 있다.

인증되지 않은 전용 준비 엔드포인트를 사용하십시오. /healthz. 이 엔드포인트는 애플리케이션과 중요한 의존성이 건강할 때 200을 반환하고 그렇지 않을 때 503을 반환해야 합니다. health 엔드포인트 구현 지침을 따르십시오.지침은 체크를 500 ms 이하로 유지하고 데이터베이스, 캐시, 중요 외부 서비스를 확인하며 각 의존성에 대한 타임아웃을 설정하는 것을 권장합니다. 반응을 유용하고 제한된 것으로 만들십시오.작은, 안정적인 반응 형태를 반환하십시오. 전체적인 상태와 기계적으로 읽을 수 있는 구성 요소 상태를 포함하되, 자격 증명, 스택 추적, 내부 호스트 이름, 또는敏感한 구성은 노출하지 마십시오. 준비 체크는 필수 의존성이 사용할 수 없을 때 명확하게 실패해야 하며, 앱이 핵심 기능을 제공할 수 있는 경우 옵션 서비스는 진단적이어야 합니다. 상태 __CAPGO_KEEP_0__ 이외의 상태도 검증하십시오.준비 엔드포인트

200

503

Validate more than the status code:

• JSON 응답이 유효하고 기대되는 field가 있는지 확인하세요.
• endpoint가 의도한 백엔드 버전까지 도달하는지 확인하세요.
• 관련 지역과 네트워크 경로에서 경로를 테스트하세요.
• 독립적인 타임아웃을 설정하여 하나의 느린 의존성이 전체 프로브를 지연시키지 못하게 하세요.
• 인프라가 프로세스 실패와 의존성 실패를 구분할 필요가 있는 경우, 독립적인 라이브니스와 리드니스를 유지하세요.

사용자의 관점에서 JSON이 손상되거나 인증서가 만료된 200 응답은 건강한 애플리케이션이 아닙니다.

체크를 릴리스 경로 내에 두세요.

CI에서 미리보기 환경에 endpoint를 실행한 후 앱에서 사용하는 API 연산을 실행한 후, 에뮬레이터 또는 디바이스 팜에서 작은 세트의 крит적 UI 흐름을 실행하세요. 환경이 생산에서 요구하는 동일한 준비 계약을 만족하지 못하는 경우 빌드는 실패해야 합니다.

Actions 작업은 간단할 수 있습니다: GitHub

• 웹 번들 및 네이티브 셸을 빌드하세요.
• 독립된 환경에 배포하세요.
• 투표 /healthz 시간 제한을 두고 진행합니다.
• 상태와 응답 형태를 검증합니다.
• 로그인과 수입이 중요한 여행을 위한 통합 테스트를 수행합니다.
• 모든 게이트가 통과하면만 게시합니다.

엔드포인트가 쓰기나 파괴적인 마이그레이션을 수행하지 않도록 하며, 자주 호출할 수 있는 안전하고 저렴한 엔드포인트로 유지합니다. 엔드포인트는 릴리스 게이트이기 때문에, 두 번째 애플리케이션은 아닙니다.

업데이트, 업데이터, 스토어와 디바이스 사이의 블라인드 스팟

릴리스가 기술적으로 완벽해도, 디바이스가 업데이트를 받지 못하거나, 설치하지 못하거나, 상태를 보고하지 못하는 경우, 운영상으로 실패할 수 있습니다. 따라서 업데이터는 앱 헬스에 포함되어야 하며, 배포 세부사항은 아닙니다.

체크아웃 유효성 검증을 변경하는 자바스크립트 번들을 고려해 보십시오. 스토어에 설치된 네이티브 셸은 여전히 사용 가능하지만, 업데이트 채널은 새로운 웹 자산을 일부 디바이스로 전달합니다. 일부 디바이스는 성공적으로 설치되지만, 다른 디바이스는 유효성 검증을 통과하지 못하거나, 네이티브 버전이 호환되지 않아 블록되기도 합니다. 스토어 대시보드는 이러한 상태의 차이를 즉시 표시하지 못합니다.

보고하는 격차는 중요합니다. 대부분의 KPI에 대해 24시간, 크래시 및 ANR율에 대해 72시간 정도 지연될 수 있습니다., 모바일 릴리스 가시도 참조. 근사한 실시간 업데이터 통계가 간격을 채우며, 어떤 기기에서 패키지를 받았는지, 설치가 실패했는지, 롤백했는지, 어떤 기기가 체크인하지 않았는지 보여줍니다.

채널을 안전 경계로 다루세요

분리된 베타, 스테이징, 및 프로덕션 채널을 사용하세요. 명시적인 호환성 규칙이 있습니다. 프로덕션 롤아웃에는 지원되지 않는 쉘에 필요한 플러그인 또는 구성 기능이 없는 네이티브 쉘을 포함하지 마세요. 채널, 릴리스, 플랫폼 및 보고된 앱 버전에 따라 수용과 실패를 추적하세요.

운영적 조절 장치들은 구체적입니다:

• 보호대기: 비호환 패키지가 지원되지 않는 쉘에 도달하지 않도록 방지하세요.
• 대상 롤아웃: 제어된 코호트에서 시작하여, 런타임 및 여정 신호가 건강할 때 확장하세요.
• 차등적 배포: 업데이터가 지원하는 경우에만 변경된 자산만 보내고, 업데이트에 필요한 작업과 데이터 양을 줄입니다.
• 롤백 보호: 설치 또는 시작 검증이 실패할 때 이전에 알려진 좋은 버블을 복원합니다.
• 버전 비교: 새로운 계열에서 크래시, 런칭, WebView 및 여행 건강을 안정적인 제어 집단과 비교합니다.

Capgo은 Capacitor 및 Electron 팀이 서명된 자바스크립트, CSS, 구성, 자산 업데이트, 대상 채널, 장치별 로그, 수용 및 실패 메트릭, 롤백 제어를 필요로 하는 옵션입니다. 그들의 Capacitor의 실시간 업데이트 개요 __CAPGO_KEEP_0__ 업데이터 모델과 팀이 배포 상태를 출시 결정과 연결할 수 있는 방법을 설명합니다.

중요한 원칙은 공급자가 아니라 feedback 루프입니다. 롤아웃은 증거를 생성해야 하며, 그 증거는 다음 계열이 버블을 받을지 여부를 결정해야 합니다.

자바스크립트 앱의 보안, 권한, 및 전송 메트릭 위생

앱은 권한, 업데이트 신뢰, 또는 전송 메트릭으로 인해 불가피한 위험을 지니고도 안정적으로 보일 수 있습니다. Capacitor 및 Electron 릴리스와 함께 플러그인 및 임베디드 웹 콘텐츠를 공격 표면의 일부로 감사해야 합니다.

다음 검사를 시작하세요:

• 플러그인 허용 목록: 사용하지 않는 플러그인 제거, 네이티브 기능 검토 및 연락처, 파일, 위치, 카메라, 마이크, 또는 외부 의도에 대한 접근을 확인하세요.
• 깊이 연결된 검토: URL 스키마 및 Android 의도 테스트. 신뢰할 수 없는 링크는 특권된 흐름을 열거나 인증을 우회하지 않도록 해야 합니다.
• 번들 검증: 업데이트를 적용하기 전에 서명 확인, 불완전하거나 예상치 못한 페이로드를 거부하고 마지막으로 알려진 좋은 번들을 회복하기 위해 유지하세요.
• 토큰 저장소: 플랫폼 보안 저장소에 자격 증명을 유지하고 자바스크립트 접근 가능한 파일 또는 제한되지 않은 로컬 저장소에 저장하지 마세요.
• 전자 기계 경계: 주 프로세스에서 특권된 API 유지, 좁은 전부 로드 인터페이스 노출, 그리고 원격 API에 도달하는 원치 않는 콘텐츠를 방지하세요.

추적성은 일치하는 제어를 필요로 합니다. 이벤트 이름, 릴리스 식별자, 작업 클래스, 그리고 실패 카테고리 기록하세요. 토큰, 결제 정보, 전체 사용자 입력 텍스트, 정확한 위치, 그리고 원본 응답 본체를 제외하고 문서화된 보안 검토가 허용하는 경우에만.

운영 필요에 따라 보관 기간 설정하고 역할에 따라 접근 제한하세요. 개인 정보 요구 사항이 적용되는 경우 삭제 또는 삭제 경로 제공하세요. 건강 이벤트는 릴리스 회귀를 분리하여 사용자 행동의 두 번째 데이터베이스가 되지 않도록 해야 합니다.

스토어 대시보드는 즉시 전체 그림을 제공할 수 없습니다. 앱 스토어 및 플레이 콘솔 추적성은 24-72 시간 보고 간을 남길 수 있으므로 스토어 신호와 업데이터 상태, 릴리스 식별자, 및 장치 측면의 실패 이벤트와 pair하세요. Google Play Console 보고서 문서 Google Play Console 보고서 문서는 지연 결과를 해석할 때 고려해야 할 보고서 컨텍스트에 대해 설명합니다.

릴리스 전에 각 새로운 권한이 명확한 목적을 가지고 있는지, 모든 로그된 필드가 소유자가 있는지, 업데이터가 신뢰되지 않는 또는 호환되지 않는 번들을 거부하는지 확인하세요. 불분명한 경계는 릴리스 차단입니다. 신호가 신뢰 또는 개인 정보 보호 실패를 노출할 때, 먼저 배포를 중단하고 그 원인인 릴리스 또는 구성이 문제를 해결하세요.

신호가 트리거되면 롤백과 복구

신호가 의미가 있으려면 안전한 액션으로 이어져야 합니다. 사고가 발생하기 전에 팀이 명확하게 생각할 수 있는 결정 tree를 작성하세요.

• 릴리스 또는 계층에서 한 번에 크래시 또는 ANR 회귀: 해당 채널을 중단하고 영향을 받은 버전과 안정 계층을 비교한 다음 네이티브 셸이 호환되는 경우 번들을 롤백하세요.
• Health endpoint가 503을 반환: 앱 배포를 중단하고 실패한 крит적 의존성을 고치세요. 서비스를 다시 시작하는 것이 도움이 될 수 있지만, 백엔드 오류를 숨기기 위해 앱 롤백을 사용하지 마세요.
• 크리티컬한 여행이 실패하면서 크래시가 정상인 경우: 영향을 받은 기능 또는 채널을 비활성화하고 응답 형태와 구성에 대해 검사한 다음 수정된 번들을 배포하세요.
• 업데이트 설치 또는 시작 유효성 검사 실패: 이전 번들을 활성화 유지하고, 릴리스를 불량으로 표시하고, 서명, 호환성 또는 자산 무결성을 조사하세요.
• 원본 권한 또는 플러그인 동작이 잘못되었습니다: 실시간 자바스크립트 업데이트만으로 충분하지 않을 수 있습니다. Fix가 원본 code, 매니페스트 변경, 특권, 또는 새로운 권한 선언이 필요할 때 스토어 릴리스를 준비하세요.

The Capacitor 실시간 업데이트 롤백 전략 __CAPGO_KEEP_0__ 실시간 업데이트 롤백 전략은 런북의 일부여야 하며, 위기 상황 중 발견되는 페이지가 아닙니다. 업데이터가 설치 또는 시작 실패를 신뢰롭게 감지할 수 있는 자동 보호가 적절합니다. 사용자가 런칭을 완료하지만 중요한 여행 중 실패할 경우 전체 사고가 여전히 필요합니다.

이 프로세스를 공식화하는 상업 압박은 분명합니다. 모바일 앱 테스트 서비스 시장은 2025 년에 7.70 억 달러로 추정되었으며, 2031 년까지 19.84 억 달러에 이를 것으로 예상되며, 연간 성장률은 17.09%입니다. 2031 년까지 $19.84 billion 17.09%약 2024년 24.9%에 따르면 시장 및 판매 리뷰 데이터. 이러한 수치는 엔지니어링 판단을 대체하지 않지만, 품질 검사를 선택사항으로 간주하는 비용을 강조한다.

각각의 사고 이후, 시간선, 가장 먼저 작동할 수 있는 신호를 식별하고, 누락된 검사를 릴리즈 게이트로 만들고, 다음 사고를 감지, 제어 및 역전하기 쉽게 만드는 것이다. 완전한 앱 헬스 체크는 단순히 실패를 보고하는 것이 아니다.

Capgo은 Capacitor와 Electron 팀이 라이브 업데이트, 목표 채널, 롤아웃 및 실패 테레메트리, 장치별 로그 및 롤백 보호를 제공하여 런타임 헬스 신호가 릴리즈 결정에 영향을 미칠 수 있도록 한다. Capgo Capgo 작성자