삭제하는 것은 한 명령어만으로 보이지만 Capgo, 그러나 삭제하기 전에 활성화된 미리보기에서 벗어나야 하며, 그 다음에 ID로 삭제할 수 있는 패키지를 제거해야 합니다. 우리는 제한된 API 키, 미리보기 조회, 리셋 처리, 패키지 삭제 및 CI 자동화와 같은 안전한 삭제 흐름을 구축할 것입니다.
Table of Contents
- 1단계: 미리보기 삭제를 위한 제한된 Capgo API 키를 생성하세요
- 2단계: Pull Request 미리보기와 패키지 ID를 식별하세요
- 3단계: 활성화된 미리보기에서 벗어나서 삭제하세요
- 4단계: API 키를 사용하여 패키지 ID로 삭제하세요
- 5단계: Pull Request가 닫히면 삭제를 자동화하세요
- 6단계: 삭제를 확인하고 실수로 삭제를 방지하세요
- FAQ
- 결론
1단계: Capgo API 미리보기 정리 API 키를 생성합니다.
Capgo pull request 미리보기 정리 흐름의 첫 단계는 미리보기 정리 작업을 수행할 수 있는 키를 생성하는 것입니다.
__CAPGO_KEEP_0__ 미리보기 정리 워크플로우에 넓은 조직 키를 넣지 마십시오. pull request는 아직 신뢰를 얻지 못한 branch에서 오를 수 있습니다. 워크플로우는 실패한 실행 중에 명령어 또는 환경 변수를 출력할 수 있습니다. narrow key는 이러한 경우에 피해를 최소화할 수 있습니다.
Capgo에서 미리보기 작업을 위해 App Preview 키를 시작하십시오. 키는 관리하는 앱 또는 미리보기 범위와 연결되어야 합니다. 팀이 역할 기반 접근 제어를 사용하는 경우, 키를 선택된 앱에만 제한하십시오. Capgo은 미리보기 키 선택을 문서화합니다. API 미리보기 키 설정.
CI 제공자의 암호화된 비밀 저장소에 비밀을 저장하십시오. 이름을 지정하여 무엇을 하는지 설명하십시오.CAPGO_PREVIEW_CLEANUP_KEY워크플로우 파일, 셸 스크립트, pull request 댓글, 또는 생성된 로그에 키를 넣지 마십시오.
키를 정리 프로세스에 환경 변수를 통해서 전달하십시오. 스크립트는 변수가 누락된 경우 실패하십시오. silent fallback은 정리 작업을 인증이 없는 요청으로 변환하거나 개발자가 명령줄에 키를 입력하도록 유도할 수 있습니다.
if [ -z "$CAPGO_PREVIEW_CLEANUP_KEY" ]; then echo "Missing preview cleanup key" exit 1
fi이 키는 배포용 번들에 사용하는 키와 분리하여 유지하세요. 배포 작업은 릴리스를 업로드해야 할 수 있지만, 정리 작업은 오직 미리보기 리소스를 삭제하기만 합니다. 분리된 키는 검토를 용이하게하고, 삭제 작업이 프로덕션 채널에 도달하는 확률을 줄입니다.
가능한 경우 보호된 환경에서 동일한 비밀을 사용하세요. 작업이 공유 채널에 접근하기 전에 승인을 요구하세요. 일반적인 pull request 미리보기 작업은 임시 채널에서만 작동해야 합니다.
주요 takeaway: 미리보기용 App Preview 키를 사용하고, 앱 범위를 제한하고, 암호화된 CI 비밀에 저장하세요.
이전 단계를 마치기 전에, 읽기 작업으로 키를 테스트하세요. 작업이 의도한 앱을 볼 수 있지만, 관련 없는 앱이나 프로덕션 워크플로에 접근할 수 없는지 확인하세요. 정리 작업의 정확한 요청 세부 정보는 완전히 공개되지 않았기 때문에, 첫 번째 테스트는 작고, 삭제 호출을 추가하기 전에 SDK 또는 Capgo 지원 지침을 검토하세요.
2단계: Pull Request 미리보기 및 번들 ID를 식별하세요
Capgo 요청 미리보기 정리 API 키는 작업이 미리보기 및 번들 ID를 알고 있을 때만 유용합니다.
__CAPGO_KEEP_0__ pull request 미리보기 정리 __CAPGO_KEEP_1__ 키는 작업이 미리보기와 번들 ID를 알고 있을 때만 유용합니다.
이미지 미리보기 채널 이름을 미리보기가 생성될 때 저장하세요. 워크플로우 출력, pull request 검사, 또는 작은 작업 메타데이터에 넣을 수 있습니다. 대시보드에서 사용자가 변경할 수 있는 표시 이름에 의존하지 마세요.
다음으로, 미리보기에 연결된 번들을 나열하세요. Capgo의 Delete Bundle 액션은 번들 ID가 필요합니다. 소스 문서는 삭제하기 전에 모든 사용 가능한 번들 ID를 가져올 수 있는 목록 호출을 지시합니다. 그 목록을 진실의 근원으로 간주하세요. 파일 이름, 커밋 해시, 또는 branch 이름에서 ID를 추측하지 마세요.
반환된 레코드를 미리보기 채널 또는 워크플로우가 제어하는 다른 값으로 필터링하세요. 그런 다음 정확한 번들 ID를 각각 유지하세요. 목록이 빈 경우, 삭제를 완료로 표시하세요. 빈 결과는 예상한 미리보기가 존재하지 않는 경우에만 실패로 간주하세요.
또한 각 미리보기에 생성된 커밋 SHA를 기록하세요. 이로 인해 삭제 전에 두 번째 확인을 할 수 있습니다. 채널 이름이 일치하지만 커밋이 일치하지 않는 경우, 검토를 요청하세요. 작은 중단은 새로운 미리보기가 생성되는 동안 오래된 삭제 작업이 실행되는 경쟁을 방지할 수 있습니다.
publish 작업이 아직 실행 중일 때 삭제하지 마세요. 미리보기 빌드와 삭제 워크플로우 사이에 의존성을 추가하거나, pull request 번호에 키를 사용하여 락을 설정하세요. 삭제 작업은 close 이벤트와 미리보기 업로드가 끝난 후에 시작되어야 합니다.
Capgo’s public API Capgo public API __CAPGO_KEEP_0__ public __CAPGO_KEEP_1__
__CAPGO_KEEP_0__ public __CAPGO_KEEP_1__ overview
Step 3: Cleanup 전의 활성 미리보기에서 전환하십시오
Step 3: 앱에서 현재 활성화된 예시를 해제하여 청소resetPreview이것은 Capgo pull request preview cleanup 흐름의 가장 중요한 부분입니다.
Think of the active preview as the version currently selected by the app. Deleting the server-side record first would leave the app pointing at something that no longer exists. Capgo blocks that state change, so your cleanup job must reset the app’s preview state before it removes the preview.
이제
UseresetPreview이미지 미리보기 상태를 직접 지우려면 필요한 경우입니다. 이 호출은 미리보기 상태를 지우려는 동일한 pull request와 앱과 연결되어야 합니다. cleanup 스크립트는 채널 이름이 일치하는 경우에만 공유 릴리스 채널이나 프로덕션 디바이스를 초기화하지 않아야 합니다.
이러한 경우 유용한 순서 규칙이 있습니다:
- pull request가 닫혔는지 확인하세요.
- 미리보기 업로드가 진행 중인지 확인하세요.
- 활성 미리보기에서 전환하거나 호출
resetPreview. - 그 상태 변경이 완료될 때까지 기다리세요.
- Delete Preview를 호출하세요.
HTTP 요청이 성공적으로 응답받은 후에도 앱이 모든 디바이스에서 상태를 변경했는지 증명하는 것은 아닙니다. 디바이스는 업데이트를 확인하기 위해 나중에 확인할 수 있습니다. 서버 측 cleanup은 미리보기 할당이 API 응답에 따라 지워졌을 때 진행할 수 있습니다. 그러나 디바이스 동작과 리소스 삭제를 분리하세요.
Capgo는 채널 기반 롤아웃 제어를 지원하며, 이 분리를 더 쉽게 이해할 수 있도록 합니다. 채널은 앱이 업데이트를 따르는 스트림을 알려주는 이름이 지정된 경로입니다. 미리보기 채널은 프로덕션 디바이스가 사용하는 동일한 채널과 같아서는 안 됩니다.
스트릭트한 경계가 필요한 팀은 문서화된 Capgo 채널 워크플로를 사용하여 미리보기 자동화를 사용하세요. 이 워크플로는 임시 채널 패턴을 설명하고 공유 기본 채널과 cleanup 작업을 분리하는 데 도움이 됩니다.
오픈 소스 업데이터 문서는 삭제 제한도 기록합니다: 활성 미리보기는 switch away 또는 reset를 먼저해야합니다. Capgo Capacitor 업데이터 저장소에서 원본을 검토할 수 있습니다. 그 원본은 CI 결정에 대한 대시보드 문구가 너무 짧을 때 유용합니다.
프로 팁: 리셋을 별도의 로그된 단계로 만듭니다. Delete Preview가 실패하면 로그에 미리보기가 활성 상태인지 또는 삭제 요청이 다른 문제인지 표시되어야합니다.
활성 상태가 사라진 후 미리보기 기록은 삭제를 위해 준비되었습니다. 리셋과 삭제를 하나의 투명한 셸 라인으로 combination하지 마십시오. 두 개의 명확한 명령은 다시 시도하기가 더 쉬우며 감사하기도 더 쉬운 것입니다.
4단계: ID로 미리보기 패키지를 삭제하십시오. API 키를 사용하십시오.
활성 미리보기가 리셋된 후 각 미리보기 패키지를 정확한 ID로 삭제하십시오. 이 때 Capgo cleanup 키는 pull request로 남아있는 저장 객체를 삭제합니다.
2단계의 패키지 목록에서 시작하십시오. 매칭 ID를 찾으면 Capgo SDK 또는 현재 사용 가능한 API 공개 메서드를 통해 Delete Bundle 액션을 호출하십시오.
SDK 메서드 서명 또는 Capgo 지원을 통해 현재 요청 형식을 확인하십시오. 확인한 후 팀 내부의 runbook에 메서드와 응답 형식을 기록하십시오. runbook에는 API 버전, 필요한 식별자, 그리고 재시도 로직이 처리할 수 있는 오류 코드를 포함해야합니다.
스크립트에서 건전지 모드 사용. 삭제 요청을 보내지 않고 미리보기 채널과 삭제할 번들 ID를 출력해야 합니다. 여러 닫힌 pull request에 대해 이 모드를 실행하고, 프로덕션 채널을 제외하고 빈 목록을 와일드 카드로 처리하지 않는지 확인하십시오.
안전한 삭제 루프는 세 개의 게이트를 가지고 있습니다.
- 잘못된 번들 ID를 거부하십시오.
- pull request 미리보기와 일치하지 않는 번들의 채널을 거부하십시오.
- 소유권 확인이 통과되면 삭제만 수행하십시오.
그런 다음 각 응답을 유형별로 처리하십시오. 성공적인 삭제는 완료로 기록할 수 있습니다. 찾을 수 없는 응답은 이전에 다시 시도한 리소스가 삭제되었다는 것을 알고 있다면 이미 깨끗한 것으로 처리할 수 있습니다. 권한 오류는 작업을 실패시키고 소유자에게 알리십시오. 속도 제한은 일시적인 실패만 재시도하고 최대 실행 시간을 설정하여 CI 큐에 고착된 청소 작업이 소비되지 않도록 하십시오.
모든 오류를 재시도하지 마십시오. 잘못된 ID는 세 번의 시도 후 유효하지 않습니다. 인증 오류는 일반적으로 키 범위가 잘못되었다는 것을 의미합니다. 일시적인 실패만 재시도하고 최대 실행 시간을 설정하여 CI 큐에 고착된 청소 작업이 소비되지 않도록 하십시오.
미리보기 삭제와 번들 삭제는 분리되어야 합니다. 미리보기 채널을 삭제하는 것은 모든 번들이 삭제되었다는 것을 자동으로 증명하지 않습니다. 작업은 각 ID에 대한 결과를 유지하고, API이 지원하는 경우 최종 목록 요청을 수행해야 합니다. 만약 어떤 번들이 남아 있다면 ID를 보고 중단하십시오. 성공을 암묵적으로 주장하지 마십시오.
비밀을 포함하지 않는 삭제 로그를 유지하세요. pull request 번호, preview 이름, bundle ID, 요청 결과 및 타임스탬프를 로깅하는 것은 괜찮습니다. API 키, 인증 헤더 또는 요청 객체를 로깅하지 마십시오. 요청 객체는 인증 키를 포함할 수 있습니다.
이 방법은 로그가 인증 정보를 유출하는 또 다른 장소가 되지 않도록 로그에 유용한 감사 기록을 남기고, 삭제 작업이 실패한 경우 다음 실행에서 이미 삭제된 것으로 확인된 레코드를 건너뛰어 다시 시작할 수 있도록 합니다.
5단계: Pull Request가 닫히면 자동으로 삭제를 수행하세요
닫힌 pull request 이벤트에서 삭제 작업을 실행하세요. 그러나 새 preview가 삭제되는 것을 방지하기 위해 늦은 빌드가 삭제를 수행하지 못하도록 확인하세요.
이벤트 페이로드에서 저장소와 pull request 번호를 받은 후 워크플로가 받습니다. preview 채널 이름을 다시 빌드하세요. pull request 댓글이나 신뢰할 수 없는 branch 변수로 제공된 채널 이름을 받지 마십시오.
이런 작업 순서가 유용합니다:
- 암호화된 비밀에서 제한된 삭제 키를 로드하세요.
- 이벤트가 닫힌 pull request인지 확인하세요.
- 기대하는 저장소와 앱에 속하는 preview가 있는지 확인하세요.
- 활성 preview 배포가 끝날 때까지 기다리세요.
- preview에서 벗어나거나
resetPreview. - 해당 preview의 bundle ID 목록을 가져오세요.
- 삭제된 각 인증된 패키지.
- 미리보기 기록 삭제.
- 워크플로우 요약에 짧은 결과를 기록.
순서가 중요합니다. 첫 번째로 삭제하면 활성 미리보기 규칙이 요청을 차단할 수 있습니다. 목록 호출을 건너뛰면 여전히 존재하는 패키지 ID를 알 수 없습니다. guessed 이름으로 삭제하면 잘못된 리소스를 조작할 위험이 있습니다.
Pull Request 번호에 대한 동시성 규칙을 사용하여 close 이벤트와 rebuild 이벤트가 거의 동시에 발생할 때, 이전 정리 작업이 새로운 배포와 경쟁하지 않도록 하세요. 폐기된 정리 작업을 취소하거나 배포 잠금이 해제될 때까지 작업을 기다리세요.
Capgo의 단일 명령 CLI 워크플로우는 빌드 및 릴리스 작업을 위한 커스텀 셸 호출의 수를 줄일 수 있습니다. 명령 이름 및 지원되는 작업에 대한 정보는 Capgo CLI 명령 문서를 참조하세요. Capgo CLI 명령 문서. CLI를 사용하여 인증된 명령을 얻을 때 사용하십시오. SDK 또는 공개 API를 사용하여 직접 요청이 필요한 정리 작업을 수행할 때 사용하십시오.
정리 작업을 푸시 이벤트와 함께 실행하지 마십시오. 푸시 작업은 여전히 테스트 중인 미리보기가 삭제될 수 있습니다. close 이벤트는 정상적인 정리 작업을 트리거하는 올바른 이벤트입니다. 실패한 작업에 대한 수동 워크플로우 디스패치를 추가하여 복구할 수 있습니다.
보존 기간을 설정하세요. close 이벤트가 누락된 경우 예약된 작업이 팀의 허용 테스트 기간보다 오래된 미리보기를 찾을 수 있습니다. 이 작업은 일반적인 close 훅보다 엄격한 보안 조치를 필요로 합니다. 미리보기가 명확한 소유자와 만료된 타임스탬프를 가진 경우에만 선택해야 합니다.
GitHub 액션에 대해, Capgo 권한을 좁게 유지하고 GitHub 액션 통합 문서에서 설명하는 것과 같이 Capgo에 필요한 값만 전달합니다.
이제 개발에 필요한 속도는 충분히 빠르며, 정리 작업을 무작위로 하는 청소 도구가 아닙니다.
6단계: 정리 작업을 확인하고 실수로 삭제되는 롤아웃을 보호합니다.
Capgo pull request preview 정리 작업 루프를 종료합니다. 단순히 삭제 응답만으로는 안전한 릴리스 프로세스를 보장하지 않습니다.
정리 작업이 완료된 후에 다시 프리뷰 채널을 확인합니다. 더 이상 활성 프리뷰로 나타나지 않는지 확인합니다. 그런 다음 동일한 앱과 필터를 사용하여 번들 목록을 확인합니다. 기대되는 결과는 대상 번들 ID가 삭제되었지만 프로덕션 번들이 남아 있는 것입니다.
이 작업 요약에 다음 값을 저장하세요:
- 저장소와 pull request 번호.
- 프리뷰 채널 이름.
- 소유권 확인을 위해 사용한 커밋 SHA.
- 찾은 번들 ID.
- 삭제된 번들 ID.
- 에러를 반환한 ID.
정확한 상태를 사용하세요. "청소된" 상태는 모든 검증된 대상이 사라졌다는 것을 의미합니다. "이미 청소된" 상태는 이 실행 이전에 리소스가不存在했다는 것을 의미합니다. "검토가 필요합니다"는 하나 이상의 검사가 실패했다는 것을 의미합니다. 부분 삭제를 성공으로 표시하지 마세요.
code에 프로덕션 가드를 추가하세요. 기본 또는 릴리스 채널과 같은 채널 이름을 거부하세요. 또한 미리보기 앱의 메타데이터와 일치하지 않는 번들을 거부하세요. 가드가 실패하면 닫혀야 합니다. 스크립트가 대상에 대한 자신감이 없으면, 스크립트는 중단되어야 합니다.
롤백과 청소는 분리하세요. 롤백은 장치가 받는 번들의 목록을 변경합니다. 청소는 이전 미리보기 리소스를 삭제합니다. pull request가 닫힌 후 테스트에서 버그가 발견되면, 조사하기 위해 번들을 필요로 할 수 있습니다. 팀이 종종 병합 후 디버깅을 하기 때문에, 이벤트가 도착한 즉시 삭제하는 대신 짧은 보존 기간을 설정하세요.
세 가지 일반적인 실패 패턴을 감시하세요:
- 활성 미리보기 오류: 리셋 또는 switch away 후 Delete Preview를 다시 시도하세요.
- 번들 ID가 누락되었습니다: 리스트 액션을 다시 실행하세요. 번들을 추측하지 마세요.
- 권한 오류: 키 범위에 대해 검토하세요. 필요한 경우 새로운 키를 발급하세요.
청소 키를 보안 정책에 따라 일정에 따라 회전하세요. 로그 또는 커밋에 나타난 경우 즉시 회전하세요. 새로운 키는 이전 키가 취소되기 전에 테스트되어야 합니다. 노출이 즉시 취소해야 하는 경우는 예외입니다.
보안 검토에서 SDK 및 인증된 Capgo 지침에 대한 문서적 결핍을 언급하는 것이 필요합니다. SDK 구현에 대한 원천으로 SDK과 인증된 Capgo 지침을 취급하고 SDK 요청 계약을 버전 관리하십시오.
주요 takeaway: code 삭제 후에 미리보기 및 번들 목록을 확인하고 code에서 프로덕션 목표를 차단하고 부분 청소가 실패로 보고하십시오.
한 명령어는 경계를 명확히 할 때만 유용합니다. 미리보기를 추적하십시오. 예측 가능한 채널 이름을 채택하십시오. 릴리스 변경 사항을 따로 되돌리십시오. 그런 다음 청소 작업이 라이브 트래픽에 영향을 주지 않도록 미리보기를 삭제하십시오.
FAQ
Capgo 활성 pull request 미리보기를 삭제할 수 있나요?
No. 활성 미리보기는 먼저 switch away 해야 하거나,
or you must call
(원어 그대로 유지)resetPreview. After the active state clears, run Delete Preview. This rule is the main detail to remember when setting up a Capgo pull request preview cleanup API key in CI.
Capgo 프리뷰를 정리하기 위해 Capgo ID가 필요합니까?
Capgo 키 종류는 CI에서 미리보리 청소에 사용해야 하나요?
API
Capgo를 사용하여 App Preview 키를 제한하여 미리보기 정리에 사용하고, CI 제공자의 암호화된 비밀 저장소에 저장합니다. 앱 또는 필요한 범위에만 키를 제한하고, 프로덕션 업데이트를 게시하는 데 사용하는 키와 분리합니다. 이로 인해 Capgo 정리 작업을 검토하고 rotate하는 것이 더 쉬워집니다.
pull request가 닫혔을 때 정리를 자동화할 수 있나요?
네. 닫힌 pull request 이벤트를 트리거하고, 활성 배포 작업이 끝나기 전에 미리보기를 초기화한 다음, 목록 ID를 나열하고, 확인된 매치를 삭제하고, 결과를 확인합니다. 동시성 제어를 추가하여 지연된 빌드가 정리 작업과 경쟁하지 않도록 합니다.
Capgo 정리 요청이 실패하는 이유는 무엇인가요?
일반적인 원인은 활성 미리보기, 부족한 목록 ID, 또는 필요한 범위가 없는 키입니다. 미리보기를 초기화한 다음, 목록 호출을 반복하고, 키 권한을 검사합니다. 요청 세부 정보는 API 또는 SDK 버전에 따라 달라질 수 있으므로, 현재 메서드와 매개 변수를 확인하기 전에 스크립트를 변경하지 마십시오.
결론
Capgo를 사용하여 전용 미리보기 키와 엄격한 정리 순서를 사용하십시오: 활성 미리보기 초기화, 목록 ID 나열, 확인된 패키지를 삭제, 마지막으로 미리보기 제거. 닫힌 한 개의 pull request에 대해 드라이 러닝을 시작하고, 현재 SDK에서 요청 형태를 확인한 다음, 자동 정리를 활성화하기 전에 프로덕션 채널 가드를 추가하십시오.
