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

금요일 오후 자바스크립트 업데이트 가 출시되었습니다. 앱이 열리고 인증이 정상이고 충돌 카운터도 특별하지 않습니다. 그런 다음 체크아웃이 일부 장치에서 실패하는 반면 앱 스토어 및 플레이 콘솔 대시보드는 롤백 결정에 자신감을 주는 정도로 뒤떨어집니다.

그 사건은 앱 헬스 체크를 위한 약점을 드러냈습니다. 앱 헬스 체크 앱 출시를 위한 헬스 체크

내용목록

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

금요일 오후 사건으로 시작하는 이 플레이북

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

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

대부분의 KPIs에 대해 앱 스토어 대시보드는 약 24시간 지연되고, 충돌 및 ANR율에 대해 최대 72시간 지연됩니다. 스토어 수집 지연 참조에 따르면. 그 대시보드는 추세 분석에 유용하지만, 실시간 사고 중에만 롤백 트리거로 사용할 수 없습니다.실용적인 규칙:

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

이러한 앱 헬스 체크는 팀에게 3 가지 증거 층을 제공합니다:

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

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

실제 반응은 timeline으로 시작해야 합니다. 배포된 번들의 날짜, 받은 채널, 첫 번째 실패한 여행의 날짜 및 영향을 받은 버전을 기록해야 합니다. 그런 다음 모바일 팀의 사고 대응 지침 을 사용하여 주인공을 assign, 증거를 보존하고 가장 안전한 행동은 채널 일시정지, 롤백 또는 네이티브 릴리스인지 결정해야 합니다.

이 프로세스의 목적은 간단합니다: silent failure를 줄이고 나쁜 신호와 안전한 행동 사이의 거리를 줄이기 위해그리고 그 결과를 달성하기 위해 나머지 건강 체크가 설계되어야 한다.

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

금요일에 릴리스가 녹색 스토어 대시보드를 보여주더라도 사용자가 로그인, 체크아웃, 업데이트 받을 수 없다면 정의하라. "건강"은 그 사고 전에 릴리스, CI, 롤백 결정과 연결된 용어로 정의하라. 플랫폼 보고가 신뢰할 수 있는지 확인하기 위해 스토어 텔레메트리도 24시간에서 72시간 동안 눈이 먼다. 따라서 디바이스 측면의 이벤트는 플랫폼 보고가 신뢰할 수 있는지 확인하기 전에 해당 기간을 커버해야 한다.

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

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

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

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

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

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

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

Runtime Checks You Can Wire Up This Week

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

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

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

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

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

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

아래 표는 의도적으로 보수적입니다. 브리프에서 벤치마크가 제공되는 경우에는 포함됩니다. 다른 밴드는 자신의 안정적인 기준에서 선택해야 하며 UNIVERSAL LIMITS로 인위적으로 생성되지 않아야 합니다.

작업, 아닌 경보만 아니라 경보를 발생시키는 동작을 측정

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

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

건강 엔드포인트 및 CI 체크가 사용자보다 문제를 먼저 잡아내는 것

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

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

상태 __CAPGO_KEEP_0__ 이외의 것에 대해 더 많은 유효성을 검사하십시오.

Return a small, stable response shape. Include an overall status and machine-readable component states, but never expose credentials, stack traces, internal hostnames, or sensitive configuration. A readiness check should fail clearly when a required dependency is unavailable, while optional services should remain diagnostic if the app can still serve its core function.

Validate more than the status code:

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

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

체크를 릴리스 경로 내에 넣습니다.

API 연산을 사용하는 앱을 대상으로 CI에서 endpoint를 실행합니다. 그 다음에 에뮬레이터 또는 디바이스 팜에서 작은 세트의 중요 UI 흐름을 실행합니다. 빌드는 환경이 생산에서 요구하는 동일한 준비 계약을 만족할 수 없을 때 실패해야합니다.

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

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

엔드포인트는 데이터를 쓰거나 파괴적인 마이그레이션을 수행하지 않습니다. 반복적으로 호출할 수 있고 비용이 저렴하며 안전합니다. 엔드포인트는 배포 게이트이기 때문에 두 번째 애플리케이션이 아닙니다.

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

배포는 기술적으로 완벽할 수 있지만 여전히 운영상으로 실패할 수 있습니다. 디바이스가 업데이트를 받지 못하거나 설치하지 못하거나 상태를 보고하지 못하는 경우가 있습니다. 업데이터는 앱의 건강에 포함되며 배포에 대한 세부사항이 아닙니다.

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

보고하는 격차는 중요한 문제입니다. 스토어 대시보드는 대부분의 KPI에 대해 약 24시간, 크래시 및 ANR율에 대해 최대 72시간 지연될 수 있습니다. 위의 설명에 따라__CAPGO_KEEP_0__ 모바일 릴리스 가시도 참고Near-real-time 업데이터 테스트 메트릭은 시간 간격을 채우기 위해 다음을 표시합니다: 어떤 기기가 패키지를 받았는지, 설치가 실패했는지, 롤백했는지, 어떤 기기가 체크인하지 않았는지.

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

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

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

• 보호 장벽: 비호환 패키지를 지원되지 않는 셸에 도달하지 않도록 방지하세요.
• 대상 롤아웃: 제어된 코호트에서 시작하여 런타임 및 여정 신호가 건강할 때 확장하세요.
• 차등 전달: 업데이터가 지원하는 경우에만 변경된 자산만 전달하여 업데이트의 작업량과 데이터 양을 줄입니다.
• 롤백 보호: 설치 또는 시작 검증이 실패할 때 이전에 알려진 좋은 버전으로 복원합니다.
• 버전 비교: 새로운 계열과 안정적인 대조군을 비교하여 WebView, journey 건강, 시작, 충돌 건강을 비교합니다.

Capgo은 signed JavaScript, CSS, 설정, 자산 업데이트, 대상 채널, 장치별 로그, 수용 및 실패 지표, 롤백 제어를 필요로 하는 Capacitor 및 Electron 팀의 하나의 옵션입니다. 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을 반환: 앱 배포를 중단하고 실패한 중요 의존성을 고치세요. 서비스를 재시작하는 것이 도움이 될 수 있지만 백엔드 오류를 숨기지 말고 앱 롤백을 사용하지 마세요.
• 크리티컬한 여행이 실패하는 동안 크래시가 정상인 경우: 영향을 받은 기능 또는 채널을 비활성화하고 응답 형태와 구성에 대해 검사한 후 수정된 패키지를 배포하세요.
• 업데이트 설치 또는 시작 유효성 검사 실패: 이전 번들을 활성화하여 유지하고, 릴리스를 불량으로 표시하고, 서명, 호환성 또는 자산 무결성을 조사하세요.
• 네이티브 권한 또는 플러그인 동작이 잘못되었습니다: 실시간 자바스크립트 업데이트만으로 충분하지 않을 수 있습니다. code의修정에 native, 매니페스트 변경, 권한, 또는 새로운 권한 선언이 필요할 때 스토어 릴리스를 준비하세요.

The Capacitor 실시간 업데이트 롤백 전략 실행 도중 발견되는 페이지가 아닌 런북의 일부여야 합니다. 자동 보호는 설치 또는 시작 실패를 신뢰할 수 있는 업데이터가 있을 때 적절합니다. 사용자가 런칭을 완료할 수 있지만 중요한 여행 내에서 실패할 때는 전체 사고가 여전히 필요합니다.

이 프로세스를 공식화하는 상업적 압박이 분명합니다. 모바일 앱 테스트 서비스 시장은 2025 년에 7.70 억 달러로 추정되었으며 2031 년까지 17.09%의 CAGR로 19.84 억 달러에 도달할 것으로 예상됩니다. 애플 앱 스토어 거부율은 약 로 보고되었습니다. $19.84 billion by 2031 at a 17.09% CAGR, while the Apple App Store rejection rate was reported at roughly 2024년 24.9%에 따르면 시장 및 스토어 리뷰 데이터. 그러나 이러한 수치는 엔지니어링 판단을 대체하지 않습니다. 그러나 품질 검사에 대한 선택사항으로 다루는 비용을 강조합니다.

각각의 사고 이후, 시간선, 가장 먼저 작동할 수 있는 신호를 식별하고, 누락된 검사를 릴리스 게이트로 만들고, 다음 사고를 감지, 제어 및 역전하기 쉽게 만듭니다.

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