롤백 플랜 예시: Capacitor 앱을 위한 7가지 플레이북

오후 4시, 웹 레이어 업데이트가 프로덕션에 배포됩니다. 몇 분 만에 크래시 리포트가 급증하고 지원 티켓이 들어오기 시작하며, 팀은 새 JavaScript bundle이 일부 기기에서만 실패한다는 사실을 발견합니다. App Store나 Google Play 리뷰를 기다릴 수는 없지만, 설정, API, feature flag, 저장된 데이터까지 바뀌었다면 이전 파일을 복원하는 것만으로는 부족합니다. 유용한 롤백 플랜 예시는 운영자에게 무엇이 대응을 트리거하는지, 어떤 버전을 복원해야 하는지, 복구를 어떻게 검증하는지, 그리고 언제 code를 되돌리면 오히려 인시던트가 악화될 수 있는지를 알려줘야 합니다.

아래 7가지 플레이북은 특정 장애 유형에 롤백 조치를 매칭합니다. 적용 대상: Capacitor 및 Electron 앱, 다음을 통해 배포되는 릴리스 포함 Capgo 채널. 이를 런북 패턴으로 사용하되, 예시 트리거는 자체 크래시, 비즈니스, 데이터 무결성 모니터링에서 나온 기준값으로 교체하세요.

목차

• 1. 크래시 감지 시 자동 롤백
  • 트리거, 액션 및 실패 모드
• 2. 버전 히스토리 기반 차분 업데이트 롤백
• 3. 지표 악화 시 자동 롤백되는 단계적 배포
• 4. Feature Flag를 이용한 설정 전용 롤백
  • 플래그 롤백은 범위를 정한 플레이북으로 실행하세요
• 5. 사용자 동의와 수동 오버라이드를 통한 Canary 롤백
• 6. 스키마 버저닝 기반 데이터베이스 마이그레이션 롤백
• 7. 자동화된 Observability와 Post-Mortem을 통한 장애 기반 Rollback
• 롤백 플랜 사례 7가지 비교
• 이 롤백 플랜 예시를 나만의 런북으로 만들어 보세요

1. 크래시 감지 시 자동 롤백

새 web bundle로 인해 이전 릴리스에는 없던 명확한 시작 실패, JavaScript 예외, 네이티브 플러그인 오류 또는 크래시 패턴이 발생했다면 자동 롤백이 가장 적절한 첫 대응입니다. 트리거는 기계가 읽을 수 있는 형태여야 하며 버전, 채널, 디바이스 그룹, 관찰 기간과 연결되어야 합니다. 릴리스 컨트롤러는 엔지니어가 대시보드를 확인할 때까지 기다리지 않고 배포를 일시 중지하고 마지막으로 정상 작동한 bundle을 복원할 수 있습니다.

Capacitor 앱이라면 네이티브 크래시 외에도 모니터링하세요. 앱이 시작되는지, web view가 로드되는지, notifyAppReady() 완료되는지, 핵심 플러그인이 초기화되는지, 첫 번째 사용자 플로우가 성공하는지 추적하세요. Electron 팀은 렌더러 프로세스 실패, 메인 프로세스 예외, 업데이트 설치 실패, 실패한 IPC 호출을 추가해야 합니다.

실무 원칙: 자동 롤백은 먼저 문제 노출을 차단한 다음 서비스를 복구하는 순서로 진행되어야 합니다. 사용자가 의심스러운 bundle을 계속 받고 있는 동안 근본 원인을 진단하려고 시도해서는 안 됩니다.

실질적인 트리거 예시로는 릴리스 기준치보다 지속적으로 높은 크래시 발생률이나 readiness check 실패율을 들 수 있습니다. 다른 앱의 임계값을 그대로 복사하지 마세요. 프로덕션에는 보수적인 제한을 설정하고, 일반적인 디바이스 및 OS 변동성에 대해 검증하며, 단일 디바이스에만 반응하지 않도록 충분한 관측값을 요구하세요.

트리거, 액션 및 실패 모드

• 트리거: 크래시, 시작, readiness 또는 네이티브 플러그인 신호가 해당 채널의 릴리스 게이트를 초과함.
• 액션: 채널 확장을 중지하고 번들을 비정상 상태로 표시한 뒤, 이전에 서명된 번들을 재배포하고 앱 시작과 핵심 플로우를 검증하세요.
• 트레이드오프: 복구는 빠르지만, 과도하게 민감한 트리거는 무관한 디바이스나 백엔드 문제로 인해 정상 릴리스를 되돌릴 수 있습니다.
• 실패 모드: 구버전 번들이 변경된 API 또는 설정에 의존하므로 앱은 시작되지만 나중에 실패합니다. 헬스 게이트에 호환성 검사를 유지하세요.

디바이스별 진단과 크래시 상관관계 분석을 위해 이 가이드를 따라 Firebase Crashlytics를 Capacitor 앱에 연결하세요. 스테이징 채널에서 감지, 채널 동결, 재배포, 클라이언트 다운로드, 활성화, 그리고 이전 버전이 여전히 사용 가능한지 확인까지 전체 경로를 테스트하세요.

2. 버전 히스토리 기반 차분 업데이트 롤백

차등 롤백은 스타일시트, 에셋, 설정 값, 또는 JavaScript 모듈에 국한된 실패에 적합합니다. 업데이트 프로그램은 활성 릴리스와 알려진 정상 대상 간의 차이만 있는 파일을 전송하여 불안정한 연결 환경의 사용자 다운로드 부담을 줄입니다. 대상은 여전히 완전한 릴리스를 재구성할 수 있어야 합니다.

트리거는 네이티브 런타임 변경이 필요 없는, 확인된 파일 수준 결함입니다. 조치 전 활성 및 이전 manifest를 비교하고, Capacitor 또는 Electron 런타임 버전을 점검한 뒤, 해당 채널에 호환되는 서명된 bundle이 있는지 확인하세요. 결함이 이 경계를 넘어가면 파일만 복구하려 하지 말고 이전 전체 bundle을 배포하세요.

Differential delivery는 부분 복구가 아닙니다. 여러 릴리스의 파일을 임의로 조합하지 마세요. 불변(immutable) manifest를 저장하고, checksum과 서명을 검증하며, 이전의 완전한 artifact를 보관하고, 채널 히스토리에 활성 버전을 기록하세요. JavaScript bundle과 네이티브 plugin이 서로 맞지 않으면 앱은 실행되더라도 나중에 핵심 플로우에서 실패할 수 있습니다.

Capgo의 앱 버전 히스토리 운영자가 재배포 전에 정상 동작이 확인된 빌드를 찾도록 돕습니다. 각 릴리스마다 bundle identifier, 네이티브 런타임 버전, Capgo 채널, 구성 리비전, 마이그레이션 노트를 기록하세요.

이 런북을 사용하세요:

1. 결함이 웹 에셋, 설정 또는 code에 국한되는지 확인합니다.
2. 문제가 된 버전이 다른 기기에 배포되지 않도록 해당 채널을 동결(Freeze)합니다.
3. 단순히 직전 파일을 선택하는 것이 아니라, 마지막으로 호환 가능한 서명된 bundle을 선택합니다.
4. 클라이언트와 manifest가 안전한 재구성을 지원하는 경우에만 differential update를 생성합니다.
5. 앱 시작, 무결성 검사, API 호환성 및 영향을 받은 사용자 플로우를 테스트합니다.
6. Capacitor 및 Electron 클라이언트에서 다운로드, 활성화 및 롤백 완료 상태를 모니터링하세요.

재구성 실패, 체크섬 불일치, 호환되지 않는 네이티브 의존성 또는 활성화 루프는 실패 모드입니다. differential 배포를 중단하고 보관된 전체 번들을 재배포하세요. 버전 히스토리를 통해 무엇이 변경되었고 어떤 릴리스가 호환성 경계를 안전하게 넘을 수 있는지 확인할 수 있습니다. 단, 이는 테스트된 롤백 아티팩트나 마이그레이션 노트를 대체하지는 않습니다.

3. 지표 악화 시 자동 롤백되는 단계적 배포

릴리스가 시작 체크를 통과하더라도 핵심 워크플로우를 손상시킬 수 있습니다. 단계적 롤아웃을 위해 베타, 스테이징, 프로덕션 또는 고객 코호트를 별도의 Capgo 채널로 분리하세요. 한 번에 서명된 번들 하나씩만 프로모션하고, 각 채널에서 이전 호환 버전을 사용할 수 있게 유지하세요. 이를 통해 노출을 제한하면서 Capacitor 및 Electron 클라이언트를 위한 직접적인 복구 경로를 확보할 수 있습니다.

프로모션 전 릴리스 게이트를 설정하세요. 체크아웃 변경의 경우 크래시만 보지 말고 결제 완료를 모니터링하세요. 메시징의 경우 전송 지연 시간과 전송 성공 여부를 확인하세요. 헬스케어 동기화의 경우 레코드 완전성을 검증하세요. 각 시그널을 동일한 대상, 기기 구성 및 채널의 베이스라인과 비교하세요. 핵심 액션이 올바르게 완료될 때만 릴리스가 정상입니다.

프로모션 시 다음 순서를 따르세요:

1. 기술 및 비즈니스 시그널을 검토할 담당자를 지정하세요.
2. 합의된 기간 동안 정의된 코호트를 Observe 하세요.
3. 모니터링 중인 지표가 승인된 임계값을 벗어나면 즉시 프로모션을 중단하세요.
4. 문제가 발생한 Capgo 채널을 동결하고, release ID, 클라이언트 버전, 설정, 메트릭 증거를 보존하세요.
5. 해당 코호트에 마지막 호환 번들을 다시 배포하세요.
6. 대표적인 Capacitor 및 Electron 기기에서 앱 실행, 업데이트 활성화, 영향을 받은 워크플로우를 검증하세요.
7. 소유자가 복구를 확인한 뒤에만 프로모션을 재개하세요.

이 Capacitor Live Updates 단계적 배포 가이드 채널 기반 릴리스를 위한 배포 컨텍스트를 제공합니다. 자동 롤백은 메트릭과 임계값이 명확할 때만 실행되어야 합니다. 결제, 개인정보, 안전 또는 데이터 무결성 관련 장애는 통계적 확신이 생기기 전이라도 즉각적인 조치가 필요할 수 있습니다.

주요 실패 원인은 대시보드가 좁다는 점입니다. 비즈니스 결과가 나빠져도 기술적 상태는 정상으로 보일 수 있고, 드문 기기·계정·네트워크 조건은 첫 코호트에서 아예 나타나지 않을 수도 있습니다. 다음 릴리스 전에 이런 사각지대를 런북에 기록해 두세요.

4. Feature Flag를 이용한 설정 전용 롤백

설정 롤백은 특정 기능에 국한된 장애에 적합합니다. 새로운 Capacitor 또는 Electron 번들은 그대로 둔 채, 원격 플래그로 문제가 된 Capgo 채널이나 대상 그룹의 위험한 경로를 비활성화하세요. 이렇게 하면 관련 없는 code를 교체하지 않고도 추천 로직, 인터페이스 변형, 선택적 동기화, 실험적 스토리지 또는 기타 보호된 동작을 복구할 수 있습니다.

Fallback은 이미 존재해야 합니다. 현재 API 및 데이터 모델과 호환되는지 확인하고, 담당자를 지정하며, 배포 전 플래그의 범위와 긴급 기본값을 기록하세요. 장애 발생 후 기존 경로를 삭제하고 플래그를 추가하면 활성화할 수 있는 수단이 남지 않습니다.

플래그 롤백은 범위를 정한 플레이북으로 실행하세요

1. 트리거: 특정 기능 오류, 워크플로우 실패, 개인정보 문제, 배터리 이슈 또는 비즈니스 회귀가 팀이 합의한 임계값을 넘는 경우입니다.
2. 액션: 영향을 받는 Capgo 채널 또는 대상 그룹에 대해 플래그를 비활성화하세요. 클라이언트가 변경 사항을 수신했는지 확인한 후, 대표 Capacitor 및 Electron 기기에서 fallback을 테스트하세요.
3. 확인 사항: 활성 플래그 상태, 관련 이벤트, 시작 동작 및 영향을 받은 워크플로우를 점검하세요. 팀이 결함을 격리하는 동안 새 bundle을 그대로 두세요.
4. 트레이드오프: 변경은 빠르고 범위가 좁지만, 공유 의존성, 호환되지 않는 native code, 또는 손상된 데이터를 복구할 수는 없습니다.
5. 실패 모드: 업데이트가 전달되지 않거나, 시작 시 무시되거나, 캐시에 남아 있을 수 있습니다. 각 관련 이벤트와 함께 플래그 상태를 로그로 남기고 캐시 만료를 정의하세요.

트레이드오프를 평가하려면 feature flag 구현 가이드 Capgo 워크플로우에서 이 제어를 구조화하세요. 핵심 기능에는 로컬 긴급 기본값을 유지하세요. 설정을 가져올 수 없으면 fail closed로 처리하세요. 보안 및 개인정보에 민감한 기능은 control plane 장애 시 접근을 유지하지 말고 비활성화해야 합니다.

5. 사용자 동의와 수동 오버라이드를 통한 Canary 롤백

Canary 릴리스는 텔레메트리상 정상으로 보일 수 있지만, 특정 엔터프라이즈 계정, 사용자 역할 또는 통합 환경에서는 실패할 수 있습니다. 해당 그룹에 명확한 fallback과 문제 보고 방법을 제공하세요. 이들의 피드백은 집계된 메트릭이 놓칠 수 있는 워크플로우나 사용성 문제를 드러낼 수 있습니다.

사용자용과 운영자용 제어를 분리하세요. 사용자 대상 액션은 장애가 발생한 워크플로우 외부에서도 사용할 수 있어야 하며, 되돌리면 무엇이 바뀌는지 설명하고 활성 번들, native app 버전, Capgo 채널, 디바이스, 타임스탬프를 수집해야 합니다. Capacitor 앱의 경우 이전 웹 번들이 설치된 native shell과 호환되는지 확인하세요. Electron의 경우 fallback이 패키징된 데스크톱 런타임과 호환되는지 확인해야 합니다.

릴리스 전 Canary 트리거를 설정하세요:

• 트리거: 특정 세그먼트에서 반복 opt-out이 발생하거나, 리포트가 몰리거나, 기술 메트릭이 합의된 임계값을 넘으면 채널을 동결하세요.
• 사용자 액션: fallback 선택지를 보여주고, 동의와 진단 컨텍스트를 기록한 뒤, 사용자를 이전 호환 번들로 되돌립니다.
• 운영자 조치: 추가 노출을 중단하고 보고서를 검토한 뒤, 카나리 채널을 안정적 빌드로 전환하세요. 제어 평면이나 클라이언트 UI가 사용 불가능할 수 있으므로 수동 오버라이드 기능을 유지하세요.
• 트레이드오프: 동의는 투명성을 높이고 문제를 조기에 발견하는 데 도움이 되지만, 버전 혼재는 지원 업무를 늘리고 비교를 복잡하게 만듭니다.
• 실패 모드: 사용자가 컨텍스트를 전송하지 않고 롤백할 수 있거나, 변경된 백엔드에서 구형 클라이언트가 실패할 수 있습니다. 이를 OTA 업데이트를 위한 사용자 동의 모범 사례 소통 및 옵트아웃 설계의 일부로, 서버 호환성을 유지하거나 제어된 기능 롤백을 수행하세요.

이 롤백을 서버 측 비호환성 해결책으로 제시하지 마세요. 백엔드 계약이 변경된 경우, 먼저 호환성을 복원하거나 영향을 받는 워크플로를 비활성화 상태로 유지하세요.

6. 스키마 버저닝 기반 데이터베이스 마이그레이션 롤백

번들 롤백은 비호환 스키마를 복구할 수 없습니다. Capacitor 또는 Electron 클라이언트가 이전 code으로 돌아가더라도, API 또는 로컬 데이터베이스는 여전히 새 필드, 변경된 타입, 또는 부분적으로 마이그레이션된 데이터를 기대할 수 있습니다. 그 결과 읽기 실패, 쓰기 거부, 또는 잘못된 레코드가 발생할 수 있습니다.

마이그레이션을 복구 경로가 포함된 독립적인 릴리스로 취급하세요. 확장 단계로 시작하세요: 기존 표현을 제거하지 않고 호환되는 필드나 테이블을 추가합니다. 두 가지 형식을 모두 읽고 쓰는 code를 배포한 후, 검증과 함께 기존 레코드를 마이그레이션합니다. 트래픽 전환을 의도적으로 수행하세요. 이전 클라이언트가 더 이상 필요하지 않을 때까지 레거시 구조를 제거하지 마세요. 이를 통해 새 스키마가 배포된 동안에도 Capgo 채널 롤백이 가능하게 유지됩니다.

리뷰 대상: 롤백 안전한 데이터베이스 마이그레이션 트랜잭션 마이그레이션, 후방 호환 스키마, 데이터베이스 및 애플리케이션 배포 분리를 다룹니다. 이러한 제어를 결제 기록, 주문, 환자 정보 및 안전하게 재생성할 수 없는 기타 데이터에 적용하세요.

배포 전에 복구 경로를 지정하세요:

• 애플리케이션 롤백: 현재 스키마를 읽을 수 있음을 확인한 뒤에만 이전 Capacitor 번들 또는 Electron 패키지를 복원하세요.
• 기능 롤백: 호환되는 스키마 변경은 유지하면서 새 쓰기 경로 또는 기능 플래그를 비활성화하세요.
• 마이그레이션 복구: 영향받은 쓰기를 중단하고 레코드를 검사한 뒤, 검토된 forward-fix 또는 복구 절차를 실행하세요.
• 데이터 복원: code 되돌리기로 데이터 정합성을 복구할 수 없다면 백업이나 시점 복구(PITR)를 사용하세요.

forward 및 복구 스크립트를 계속 검토하세요. 운영 환경과 유사한 데이터로 테스트하고, 지원되는 경우 트랜잭션이나 savepoint를 활용하세요. 장애 발생 시 파괴적인 rollback SQL을 생성하지 마세요. 애플리케이션 상태, 데이터 유효성, 쓰기 호환성에 대한 성공 조건을 정의하고, 각 결정마다 별도의 담당자를 지정하세요. 스테이징에서 연습하지 않은 마이그레이션 계획은 신뢰할 수 있는 rollback plan 예시가 아닙니다.

7. 자동화된 Observability와 Post-Mortem을 통한 장애 기반 Rollback

Capgo 채널은 정상적으로 배포 중이어도 특정 Capacitor 또는 Electron 코호트에서 출시 후 오류가 발생할 수 있습니다. 지속적인 크래시 신호, readiness check 실패, API 흐름 중단, 데이터 무결성 오류 확인 등 배포 전에 장애 트리거를 정의하세요. 알람이 발생하면 채널 확장을 중단하고 현재 bundle, native app 버전, 채널, rollout 상태, 영향받은 코호트, 에러 카테고리, 타임스탬프를 기록하세요. 배포 상태를 바꾸기 전에 이 증거를 먼저 확보해야 합니다.

배포 및 복구 지표에 관한 DORA 가이드라인 rollback을 변경 실패 신호이자 복구 이벤트로 규정합니다. 릴리스 식별자와 rollback 결과를 저장한 뒤, 탐지부터 복구까지 걸린 시간, 영향을 받은 세션 또는 디바이스 수, 복구 후 에러율을 비교하세요. 이 지표를 통해 복구된 bundle이 문제를 해결했는지 확인할 수 있습니다.

인시던트를 짧게 기록된 순서로 진행하세요:

1. 트리거: 경보를 크래시, 준비 상태, API, 비즈니스 또는 데이터 신호와 대조해 확인하세요.
2. 동결: 전체 롤백보다 영향 범위를 더 잘 제한할 수 있다면 채널 확장을 중단하고 기능 플래그를 비활성화하세요.
3. 보존: 로그, 트레이스, 버전 히스토리, 채택 상태, 영향받은 세그먼트 세부 정보를 저장하세요.
4. 롤백: Capacitor 또는 Electron용 마지막으로 호환되는 bundle을 다시 배포하고 네이티브 버전 호환성을 고려하세요.
5. 확인 사항: 시작 및 핵심 플로우를 테스트한 후, 실패 신호가 감소하는지 확인하세요.
6. 리뷰: 원인, 탐지 실패, 결정 사항, 런북 변경 내용을 기록하세요.

롤백 실패 자체가 트리거입니다. 복구된 버전이 크래시되거나, 시작되지 않거나, 동일한 API 오류가 재발한다면 마지막으로 정상 확인된 채널이나 수동 배포 경로로 에스컬레이션하세요. 다음을 활용하세요 Forge Reliability 근본 원인 가이드 를 사용해 조사를 구조화하세요. 증거가 남아 있는 동안 블레임리스 포스트모템을 진행하고, 각 시정 조치에 담당자를 지정하며, 그 결과 도출된 준비 상태 점검이나 채널 가드레일을 리허설하세요.

롤백 플랜 사례 7가지 비교

이 롤백 플랜 예시를 나만의 런북으로 만들어 보세요

모든 인시던트에 하나의 롤백 메커니즘을 선택하지 마세요. 가장 좁은 범위의 안전한 조치부터 시작하세요. 데이터 무결성을 유지하면서 실패한 경로를 비활성화할 수 있는 기능 플래그가 있다면 먼저 사용하세요. 릴리스 자체가 불안정하다면 채널 확장을 중단하고 자동화된 크래시 및 준비 상태 게이트를 갖춘 단계별 채널 제어를 사용하세요. 실패가 공유된 code, 구성 또는 호환되지 않는 API에 영향을 미친다면 마지막 호환 가능한 번들을 복원하고 전체 사용자 플로우를 검증하세요.

가장 어려운 결정은 데이터와 관련됩니다. 번들 롤백은 스키마 마이그레이션, 부분 쓰기 또는 서버 사이드 동작 변경을 되돌리지 않습니다. 이러한 인시던트에서는 위험한 쓰기를 동결하고 데이터 소유자를 참여시켜 이전 클라이언트가 자동으로 더 안전하다고 가정하기보다 마이그레이션 안전 절차를 따르세요. Knight Capital의 2012년 실패 사례는 이전 바이너리를 복원하는 것만으로는 충분하지 않은 이유를 보여줍니다. 서버에 비활성 상태의 레거시 기능이 남아 있었고, 재사용된 플래그가 이를 활성화했으며, 롤백 시도에도 문제 있는 동작이 환경 전체에서 활성화된 채로 남았습니다. 이 인시던트는 대략 3억 9,700만 건의 잘못된 주식 체결, 약 70억 달러의 명목 포지션, 그리고 초기 보고된 세전 손실 약 4억 4,000만 달러, 이후 광범위한 보도에서 4억 6,000만 달러 수준으로 집계되었으며, 이 Knight Capital 롤백 실패 사례에 기록된 바와 같습니다.

Spotify의 Storm 배포는 스테이트풀 시스템에 또 하나의 유용한 원칙을 제공합니다. 두 개의 완전한 토폴로지 버전을 유지하고, 컨슈머 위치를 보존하며, 되돌릴 수 있는 활성화 방식을 사용하면 운영자는 스트림을 잃지 않고 이전 버전으로 복원할 수 있습니다. 이는 Spotify의 Apache Storm 배포 사례에서 설명합니다. 이에 대응하는 Capgo 설계는 이전 서명된 번들을 유지하고, 버전별 헬스 게이트를 보존하며, 이전 릴리스를 제거하기 전에 호환성을 확인하는 것입니다.

이 아이디어들을 짧은 의사결정 트리로 만들어 보세요:

• 기능별 실패: 기능 플래그를 비활성화하고, 폴백을 확인한 후 원인을 조사하세요.
• 릴리스 불안정: 채널을 동결하고, 마지막 호환 bundle을 재배포한 뒤 복구 상황을 모니터링하세요.
• 세그먼트별 불확실성: 프로모션을 중단하고, 카나리 피드백과 수동 오버라이드를 사용하세요.
• 스키마 또는 데이터 리스크: code를 무작정 롤백하지 마세요. 변경 사항을 동결하고 마이그레이션 또는 데이터 복구 계획을 실행하세요.
• 원인 불명: 먼저 증거를 확보하고, 노출 범위를 제한한 뒤 가장 좁은 범위에서 되돌릴 수 있는 조치를 선택하세요.

오늘 하나의 플레이북을 선택하세요. 트리거, 담당자, 정확한 롤백 명령어나 대시보드 액션, 검증 단계, 에스컬레이션 경로를 작성하세요. 다음 프로덕션 릴리스 전에 스테이징 채널에서 실행해 보세요. 실패한 업데이트, 깨진 리디네스 신호, 설정 되돌리기, 호환성 체크를 포함해야 합니다. 롤백이 사고 후 작성된 문단이 아니라 실제로 연습된 운영 절차일 때 팀은 더 빠르게 복구됩니다.

Capgo은 CapacitorJS 및 Electron 앱에 서명된 Live Update를 제공합니다. 대상 채널, 버전 히스토리, 기기별 로그, 채택 및 실패 지표, 차등 배포, 자동 롤백 보호 기능을 지원합니다. 사용 Capgo 하여 앱에 맞는 롤백 계획 예시를 테스트된 릴리스 및 복구 워크플로우로 전환하세요.