Capgo Rollout 중단 vs Rollback: 사용할 때

배포 중단은 더 많은 장치에 도달하는 것을 막습니다. 롤백은 영향을 받은 장치들을 알려진 좋은 버전으로 이동시킵니다. Capgo Capgo는 두 가지 모두를 지원하기 때문에, 문제를 해결하기 전에 다음에 무엇을 할지 결정할 수 있습니다.

이러한 단계를 따라 올바른 행동을 선택하고, 그 효과를 확인하고, 반복적인 사고를 줄이세요.

우리는 Google Play, Amazon Appstore, Microsoft의 CodePush, Bitrise, Nearform, Digia에서 6개의 공개 가이드를 읽었습니다. 4개의 가이드는 배포 중단과 롤백을 분리된 동작으로 설명했으며, 2개의 가이드는 롤백을 생략하거나 배포 중단만 설명했습니다. 6개의 가이드 중에서, 6개 모두는 회복을 확인하기 위한 분석 또는 장치 검사를 설명하지 않았으며, 반복적인 사고를 예방하는 워크플로도 설명하지 않았습니다. 배포 중단과 롤백을 올바르게 선택하고, 그것이 작동했는지 확인하는 것은 공개 릴리스 지침에서 남겨진 틈을 닫습니다.

목차

• 1단계: Capgo에서 릴리스 제어를 설정하세요
• 2단계: 배포 중단 또는 롤백을 선택하세요
• 3단계: 조사하는 동안 더 이상 장치에 노출되지 않도록 하세요
• 4단계: 사용자가 안정적인 버전을 필요로 할 때 롤백하세요
• 5단계: 분석 및 장치 검사를 통해 회복을 확인하세요
• Step 6: Repeat 사고를 예방하는 더 안전한 릴리즈 워크플로우
• FAQ
• 결론

Step 1: Capgo에서 릴리스 제어를 설정하십시오

사고 이전에 팀이 릴리즈 채널과 안정적인 번들을 알 수 있도록 하세요. 릴리즈 채널은 앱 기기에게 업데이트를 지시하는 이름이 붙은 레인입니다. 안정적인 번들은 그 레인으로 전송되는 웹 code입니다.

Capgo에서, 점진적인 릴리즈는 안정적인 번들을 유지하면서 선택한 그룹에게 별도의 릴리즈 목표를 전송할 수 있습니다. 그로 인해 새로운 번들이 더 넓은 사용자 기반에 도달하기 전에 제어점을 가질 수 있습니다. 점진적인 릴리즈 제어를 릴리즈를 활성화하기 전에 점진적인 릴리즈 제어를 검토하세요. production 환경에서 활성화하기 전에.

OTA 업데이트는 앱의 업데이트 가능한 __CAPGO_KEEP_0__을 공중에서 업데이트합니다. 앱 스토어에서 설치된 네이티브 앱 바이너리를 교체하지 않습니다. 공중에서 업데이트하는 이 전달 방법을 설명하는 용어입니다. 이 경계를 기억하세요: 네이티브 플러그인 변경이나 앱의 네이티브 설정 변경이 필요한 경우, 번들 롤백은 이를 제공하지 않습니다.

An OTA update changes the app’s updateable code over the air. It doesn’t replace the native app binary installed from an app store. The term over-the-air update describes this delivery approach. Keep this boundary in mind: if a fix needs a new native plugin or a change to the app’s native setup, a bundle rollback won’t supply it.

출시 전, 안정 버전이 기대하는 버전인지 확인하세요. 채널 이름, 대상 버전, 롤플로우 상태를 확인하세요. 채널 이름의 타이포 또는 대상 버전이 오래된 경우, 분초가 중요한 상황에서 잘못된 제어로 보내는 것을 막을 수 있습니다.

이제 이름이 지정된 릴리즈 오너, 알려진 좋은 버전, 그리고 중단 조건이 작성된 상태여야 합니다. 이 준비는 다음 결정이 운영 조치가 아닌 혼란스러운 대시보드를 뒤지지 않는 선택으로 바꿉니다.

주요 takeaway: 정지: 새로운 노출을 제한합니다. 롤백: 사용자가 받을 버전을 변경합니다.

2단계: 정지 또는 롤백을 선택하세요

For the Capgo pause rollout vs rollback decision, ask one question first: are you trying to stop more devices from getting the target, or move devices off a target that’s already causing harm? A pause limits new exposure. A rollback clears the target and returns devices to the stable fallback on their next update check.

__CAPGO_KEEP_0__ 정지 롤플로우 vs 롤백 결정에 대해 묻는 첫 질문은, 대상 버전을 받지 않도록 더 많은 장치를 멈추려는 것인지, 이미 문제를 일으키는 대상 버전에서 장치를 옮기는 것인지 여부입니다. 정지는 새로운 노출을 제한합니다. 롤백은 대상 버전을 지우고 장치를 다음 업데이트 확인 시 안정적인 기본 버전으로 되돌립니다.

사용자가 안전하지 않은 대상에 대해 rollback을 선택할 때, 또는 팀이 알려진 좋은 버전이 더 안전한지 충분한 증거가 있는 경우. 단지 rollout을 중단하는 것만으로는 이미 rollout 코호트에 있는 기기에서 나쁜 대상이 제거되지 않습니다. 만약 사용자가 안정 상태로 돌아가야 한다면 rollback은 업데이트 경로를 변경하는 동작입니다.

이 Capgo 채널 CLI 참조 분리된 중단과 롤백 제어를 가진 별도의 목록입니다. 그들을 다른 동작으로 다루세요. 단지 두 가지 이름으로 같은 긴급 중단을 의미하는 것이 아닙니다.

백엔드 오류를 고치거나 미래의 네이티브 기능을 추가할 수 없습니다. 먼저 실패한 레이어를 식별하십시오. 웹 버블이 문제인 경우, 사용자들이 구제를 받을 수 있는 수준에 따라 일시 중단하거나 되돌리기를 선택하십시오.

3단계: 조사 중인 동안 더 이상 노출되지 않도록 일시 중단하십시오

컨텍스트: Capgo에 대한 페이지. 역할: UI 레이블. 보이는 곳: about.astro 페이지에. 메시지 키 `about_how_step_label` (About How Step Label)

Open the production channel and verify that you’re acting on the affected rollout. Pause it with the dashboard, CLI, or API control your team uses. Then read the channel state back. Don’t rely only on a command completing successfully; confirm the rollout now shows as paused.

Capgo의 진행 중인 롤아웃 모델에서, 기존에 롤아웃 그룹에 속한 기기는 롤아웃 대상에 남아있을 수 있습니다. 새로운 적격 기기는 다음 체크 시 안정적인 기본값을 받습니다. 이 차이점은 중요합니다: 롤아웃을 중단하면 새로운 기기가 롤아웃 그룹에 들어가지 않지만, 기존의 롤아웃 그룹을 안정적인 기본값으로 되돌리는 것은 직접적으로 이루어지지 않습니다.

다음으로, 릴리스 상세 정보를 기록하기 전에 변경을 다시 한번 확인하세요. 대상 번들, 채널, 롤아웃 중단 시간, 첫 번째 알려진 보고서를 기록하세요. 기기 또는 세션 상세 정보는 팀이 수집할 수 있는 정보입니다. 명확한 시간대는 롤아웃 그룹과 안정적인 기본값에 남아있는 기기를 비교하는 데 도움이 됩니다.

문제를 확인하기 위해 반복 가능한 경로를 확인하세요. 사용자가 로그인에 실패한 경우, 영향을 받은 기기에서 정확한 여행을 테스트하세요. 앱이 런칭 시 충돌하는 경우, 새로운 번들과 네이티브 앱 버전과 일치하는지 확인하세요. 모든 지원 보고서를 업데이트가 문제를 일으켰다는 증거로 취급하지 마세요.

조사 중인 문제의 책임자와 결정 시간을 설정하세요. 중단된 롤아웃은 책임자가 다음 단계를 결정하지 않으면 지체될 수 있습니다. 책임자는 증거가 릴리스를 정당화할 때 롤아웃을 재개하거나, 대상이 여전히 안전하지 않다면 롤백을 선택해야 합니다.

팁: 지원팀과 릴리스 팀에 롤아웃이 중단되었다고 알려주세요. 그렇지 않으면, 한 팀은 보고서를 계속 상승시키면서 다른 팀은 롤아웃이 이미 반전되었다고 가정할 수 있습니다.

이제 새로운 기기들이 롤아웃 그룹에 더 이상 들어가지 않아야 합니다. 채널 상태를 확인하고 이전에 그룹에 속하지 않은 기기의 동작을 확인한 후 롤백 또는 재개로 이동하세요.

Step 4: 사용자가 안정적인 버전을 필요로 할 때 롤백

컨텍스트: Capgo에 대한 페이지. 역할: UI 레이블. 보이는 곳: about.astro 페이지. 메시지 키 `about_how_step_label` (About How Step Label).

In Capgo, open the affected channel and review its build history. Choose the version you want to restore, then confirm that it is the correct stable bundle for this app and channel. Capgo’s __CAPGO_KEEP_0__에서 영향을 받은 채널을 열고 빌드 히스토리를 검토하세요. 원하는 버전을 선택한 후, 이 앱과 채널에 대한 올바른 안정적인 번들을 확인하세요. __CAPGO_KEEP_1__의 롤백 문서 롤백 문서

롤백 문서

롤백 문서의 설명은 대시보드 경로와 장치가 선택한 빌드를 다음 업데이트를 확인할 때 받는다는 것을 언급합니다.

이벤트를 분석하기 위해 발생한 버블을 보존하고, 보관 기간이 정해져 있지 않다면. 릴리즈 ID와 커밋은 엔지니어들이 변경 사항을 안정 버전과 비교할 수 있도록 도와줍니다. 로그를 정리하기 전에 관련 로그를 보존하고, 특히 테스트에서 문제가 발생한 이유를 이해해야 하는 경우에 특히 중요합니다.

롤백은 모든 실패의 올바른 해결책이 아닙니다. 서버 측 의존성이 문제인 경우 해당 서비스를修리하세요. 변경 사항이 설치된 바이너리에 존재하지 않는 원시 code에 의존하는 경우 원시 빌드를 준비하고 해당 변경 사항을 앱 스토어 릴리스 경로를 따라야 합니다.

5단계: 분석 및 장치 확인을 통해 복구 여부를 확인하세요

컨트롤 변경을 복구로 간주하기보다는, 롤백 또는 중단 후 장치가 무엇을 하는지 확인하세요. 먼저 활성 채널 상태를 확인한 후, 영향을 받은 릴리즈와 안정 버전 간의 업데이트 수락률, 오류율 및 장치 보고서를 비교하세요.

Capgo의 live update 분석은 수용률, 오류율 및 장치 로그를 검사하는 데 도움이 될 수 있습니다. 이러한 신호를 사용하여 특정 질문에 답할 수 있습니다: 새로운 장치가 대상 버전을 여전히 받고 있는지, 영향을 받은 장치가 안정 버블을 확인하고 있는지, 그리고 보고된 실패가 복구 후에 중단되었는지.

실패한 사용자 경로를 테스트하세요. 성공적인 다운로드는 앱이 작동하는 것을 증명하지 않습니다. 관련된 화면을 열고, 보고서가 발생한 동작을 반복하고, 앱이 예상된 상태로 도달하는지 확인하세요. 만약 이슈가 중요한 흐름과 관련이 있다면, 변경을 적용한 사람과 다른 사람이 결과를 확인하세요.

비슷한 것을 비교하세요. 오류 수의 폭발은 릴리스와 관련이 없는 이유로 발생할 수 있습니다. 서비스 문제나 트래픽의 변화로 인해 발생할 수 있습니다. 필터링을 통해 버전, 채널, 앱 버전, 장치 등이 있는 경우에만 사용하세요. 릴리스와 관련된 차이를 찾으세요. 가장 최근 업데이트를 비난하는 대신.

업데이트되지 않은 사용자도 확인하세요. 그들의 존재는 전체적인 지표가 건강하게 보이게 할 수 있지만, 영향을 받은 그룹은 여전히 버그를 보고할 수 있습니다. 대상 버전과 안정 버전의 장치 비율을 추적하고, 사용자가 실제로 실행하는 버전에 대한 지원 보고서를 연결하세요.

복구 결과와 남은 불확실성을 기록하세요. 오류가 줄어들지만 일부 사용자가 여전히 같은 이슈를 보고한다면, 이슈를 닫지 않도록 하세요. 그들은 오프라인이거나, 더 오래된 네이티브 셸을 사용하거나, 여전히 영향을 받은 버전을 사용하고 있는지 여부를 확인하세요.

복구가 확인되면, 채널이 원하는 버전을指向하고, 실패한 사용자 경로가 문제를 재현할 수 있는 장치에서 작동하는지 확인하세요. 지표는 문제의 형태를 보여줍니다. 장치 확인은 사용자가 경험하는 것을 확인합니다.

6단계: 더 안전한 릴리스 워크플로우로 반복적인 이슈를 예방하세요.

출시 전, 릴리스 계획에 중단 및 롤백을 포함시켜야 합니다. 릴리스 소유자는 노출을 중단하고 안정 상태로 돌아가도록 승인할 수 있는 사람을 알 수 있어야 합니다. 이는 일반적인 지연 시간을 제거합니다: 회의를 기다리면서 더 많은 장치가 롤아웃에 참여하는 동안.

롤아웃 대상이 테스트되는 동안 안정적인 fallback을 assign하고 유지하세요. 작은 정의된 코호트에서 시작하여, agreed 건강 신호가 제한 내에 유지될 때까지 확장하세요. Capgo는 채널 기반 릴리스 제어를 지원하므로, 팀은 테스트와 광범위한 프로덕션 배포를 분리할 수 있습니다.

릴리스 체크를 CI/CD에 넣으세요. 자동화된 프로세스는 테스트를 실행하고 변경을 배포합니다. pipeline은 테스트가 통과하면 지정된 채널에 패키지를 배포할 수 있습니다. 채널이 잘못되거나 릴리스가 승인되지 않은 상태로 배포되는 경우에도 안전하게 실패해야 합니다.

연속적인 배포 워크플로우는 소프트웨어를 릴리스 준비 상태로 유지하는 자동화된 프로세스입니다. OTA 워크플로우의 경우, 자동화가 릴리스가 승인되지 않은 변경에 대한 결정을 내리지 못하도록 하세요. 자동화는 선택한 작업을 반복적으로 수행하도록 해야 합니다.

Capgo를 사용하면 한 명령으로 채널에 패키지를 배포할 수 있습니다. 릴리스 프로세스와 함께 명령을 유지하고 배포 기록에서 대상 채널을 표시하세요. 이로 인해 온콜 엔지니어는 정확히 어떤 것을 배포했는지 추측하지 않고 쉽게 확인할 수 있습니다.

자동 보호 기능을 활성화하기 전에, 어떤 신호가 보호 기능을 트리거하고, 보호 기능이 취할 행동을 정의하세요. 일시 중단은 새로운 노출을 중단시키면서 현재 계열의 기기들을 대상으로 유지합니다. 롤백은 기기를 안정화 방향으로 지시합니다. 이러한 결과는 다르기 때문에, 하나를 다른 것으로 가정해서는 안 됩니다.

테스트 채널을 사용하여 전체 반응을 연습하세요. 무해한 변경을 게시하고 일시 중단 제어를 확인한 후 이전 버전으로 롤백 테스트하세요. 각 액션 후 기기에서 앱 동작을 확인하세요. 작성된 런북에는 채널, 명령 또는 대시보드 경로, 예상 상태 및 성공을 확인한 사람의 정보가 포함되어야 합니다.

릴리즈 노트는 버전과 목적을 포함해야 합니다. 배포 기록과 소스 변경 간의 링크를 유지하여, 오류가 나타날 때 엔지니어들이 검색 범위를 좁히도록 하세요. 팀이 시간대가 다른 인원에게 사고를 전달할 경우, 마지막으로 수행된 작업과 다음 결정 소유자의 정보를 포함하세요.

사고가 더 넓은 프론트 엔드 구현 성능 병목 현상에 지적되면, 웹사이트 개발 작업과 관련된 웹 개발자인 아미르 아레조 는 관련될 수 있습니다. 이는 Capgo의 롤아웃 제어와 별도로, 호환 가능한 앱 업데이트의 전달 및 복구를 처리합니다.

이제 릴리즈 경로에는 안정화 fallback, 소유자, 중단 규칙 및 테스트된 복구 액션이 포함되어야 합니다. 온콜 엔지니어가 압박하에 사용할 수 있는 워크플로우를 유지하세요.

FAQ

일시 중단을 Capgo의 롤아웃으로 하면 기기들이 이미 업데이트된 기기들이 롤백되나요?

1. rollout을 중단하면 새로운 대상 기기들이 rollout에 참여하지 못하지만, 이미 rollout에 포함된 기기는 대상 배포본을 유지합니다. rollout에서 사용자들을 다시 안정 상태로 되돌리려면 rollback 또는 다른 의도적인 채널 액션을 사용하세요. rollout을 변경한 후 채널 상태를 확인하고, 대상 기기를 확인하여 결과를 확인하세요.

어떤 경우에 rollback 대신 pause를 사용해야 하나요?

rollout을 중단해야 하는 상황은 조사 중인 문제가 더 넓은 노출을 막기 위해 필요한 경우입니다. rollback은 대상이 사용자에게 피해를 주거나 영향을 받은 기기가 안정적인 배포본을 필요로 할 때 사용하세요. Capgo rollout vs rollback 선택은 즉시 필요한 것은 격리 또는 기존 코호트의 복구인지에 따라 달라집니다.

롤백은 모든 장치가 즉시 업데이트될까요?

No. rollback은 채널이 가리키는 배포본을 변경하지만, 기기는 다음 업데이트를 확인할 때까지 업데이트를 받지 않습니다. 오프라인인 기기는 재접속할 때까지 현재 배포본을 유지합니다. 채널 대상과 영향을 받은 기기 및 업데이트 상태를 확인한 후 사고를 해결한 것으로 선언하세요.

OTA 롤백은 네이티브 앱 문제를 해결할 수 있나요?

No. OTA rollback은 이전 업데이트 가능한 웹 배포본을 복원할 수 있지만, 설치된 앱 바이너리 내의 네이티브 code를 추가하거나 제거할 수 없습니다. 네이티브 플러그인 또는 앱 셸 변경으로 인한 문제가 있는 경우, 새로운 네이티브 빌드를 필요로 하는지 평가하세요. 먼저 실패한 원인인 레이어를 식별하세요.

어떤 점을 확인해야 하는지

채널의 상태와 활성 배포본을 확인한 후, 릴리스별로 업데이트 수용률과 오류를 확인하고, 영향을 받은 그룹의 기기에서 사용자 경험을 테스트합니다. 또한 아직 업데이트되지 않은 기기를 확인하여, 한 버전 또는 계층에 국한된 문제가 전체 메트릭스에 의해 숨겨질 수 있음을 확인합니다.

결론

문제를 조사하는 동안 새로운 노출을 중단할 때 사용하세요. 대상 사용자가 안정된 버전을 필요로 할 때 롤백하세요. 두 가지 제어를 미리 설정하고, 다음 프로덕션 릴리스 전에 테스트 채널에서 그들을 연습하세요.