릴리스가 늦은 밤에 출시되었습니다. 지원 팀이 깨진 화면, 로그인 실패, 또는突然 작동이 멈추는 체크아웃 흐름과 같은 문제로 깨워졌습니다. 엔지니어링 팀은 첫 번째 질문을 물었습니다: 무엇이 바뀌었나? 그 다음 방은 조용해졌습니다.
한 사람이 Git 커밋을 확인합니다. 다른 사람들은 CI 로그를 검토합니다. 제품 팀은 앱 스토어 릴리스 노트를 확인했지만 "버그 수정 및 개선" 이외의 정보가 거의 없었습니다. 슬랙에서 마지막으로 변경된 구성 설정을 기억하는 사람이 있지만, 누구도 그것이 스토어 빌드에, 라이브 업데이트 번들에, 또는 둘 다에 적용되었는지 확신하지 못했습니다. 그 순간 팀은 changelog가 앱 버전 기록과 다르다는 것을 배웠습니다.
If your mobile team ships through the stores and also pushes code outside the store review path, your operational risk doubles unless version history is treated as a system, not a note-taking habit. Teams that have already felt the pain of review delays, rejected submissions, or unclear release provenance will recognize the pattern in this 애플 스토어 거부 사후 분석. The lesson is simple: when release state is ambiguous, incident response slows down exactly when speed matters most.
목차
- 버전 기록의 중요성에 대한 중요한 순간
- 애플 버전 기록이 정말 무엇인가
- 4가지 이유로 앱이 현재 버전 기록을 필요로 한다
- 앱 스토어 히스토리 vs 라이브 업데이트 히스토리
- 버전 히스토리 데이터 모델을 설계하는 방법
- 실제로 Capgo를 사용하는 방법
- 기록 관리에서 릴리스 제어까지
버전 기록의 중요성이 실현되는 결정적 순간
실패는 버그 자체가 아니라 버그를 보고 정확한 릴리스를 식별하는 시간 차이 때문입니다.
모바일 팀은 결함을 견딜 수 있습니다. 시간을 소모하는 것은 불확실성입니다. 만약에 승인된 바이너리, 전달된 패키지, 받은 채널, 변경을 트리거한 사람을 알 수 없다면, 매 분마다 고고학이 됩니다. 개발자들은 커밋 메시지를 검색합니다. 지원 팀은 스크린샷을 전달합니다. 제품 팀은 이슈가 모든 사용자에게 영향을 미치는지 아니면 특정 세그먼트만 영향을 미치는지 여부를 물어봅니다. nobody가 단일 운영 기록을 가지고 있지 않습니다.
운영적 단절은 압박하에 나타납니다
릴리스 기록을 저장하면 공공 마일STONE을 제공합니다. 그것은 버전이 존재했음을 알려줍니다. 일반적으로 내부 이벤트의 시퀀스를 생성한 것에 대해 충분히 알려주지 않습니다. 현대 모바일 배달에서 그것은 심각한 단절입니다. 왜냐하면 앱 사용자는 종종 여러 층으로 구성된 결과를 실행합니다: 네이티브 바이너리, 웹 패키지, 자산, 기능 플래그, 및 구성
공개된 릴리스 노트는 고객에게 도움이 됩니다. 그러나 사고 중에 응답자에게 도움이 되지 않습니다.
이것을 잘 처리하는 팀은 기억이나 산발적인 도구에 의존하지 않습니다. 그들은 버전의 기록을 유지하여 모든 배포 가능한 아티팩트를 타임스탬프, 원인, 및 목적지 채널과 연결합니다. 사고가 시작되면 그들은 역사를 재구성하는 것이 아니라 그것을 읽습니다.
역사가 약해질 때 무엇이 깨지나요
약한 앱 버전 기록 시스템은 다음의 chain된 문제를 생성합니다:
- 롤백이 지연됩니다: 팀은 마지막으로 잘 알려진 버전을 결정하기 위해 토론합니다.
- 지원이 정확성을 잃습니다: agent는 보고서가 이전의 빌드 또는 최신의 패치에 속하는지 알 수 없습니다.
- 사후 분석은 흐릿합니다: 회귀가 있었지만 정확한 릴리스 순서를 증명할 수 없습니다.
- 내부적으로 신뢰가 약화됩니다: 제품, 지원 및 엔지니어는 “현재 버전”에 대한 동일한 언어를 사용하지 않습니다.
이것은 관리 작업이 아니며, 이는 생산 제어입니다.
App 버전 기록이 무엇인가요?
App 버전 기록은 애플리케이션의 모든 배포된 Git 기록입니다.repository를 넘어서, code 또는 자산이 변경되었는지, 언제 변경되었는지, 누가 릴리즈를 시작했는지, 그리고 릴리즈가 어디로 가는지 알려줍니다. 앱이 스토어 제출 외에서 변경될 수 있다면, 그 변경 사항을 native 빌드와 같은 엄격함으로 기록해야 합니다.
많은 팀이 버전 기록을 마케팅 자료로만 다룹니다. 그게 너무 좁습니다. 올바른 시스템은 하나의 감사 기록에서 바이너리, 자바스크립트 번들, 자산, 구성 변경, 롤아웃 채널, 릴리즈 메타데이터를 기록해야 합니다. 만약 배포 모델을 비교한다면, 이 차이는 traditional 버전 관리와 OTA 업데이트 사이의 핵심입니다. traditional versioning and OTA updates in Capacitor.
changelog는 사용자에게, 기록 시스템은 운영자에게 있습니다.
사용자에게는 '무엇이 새로운가?'를 알려주는 릴리즈 노트가 있습니다. 운영자에게는 '무엇이 정확히 배포되었고, 언제, 누구에 의해, 그리고 어떻게 그것을 되돌릴 수 있는가?'를 알려주는 기록 시스템이 있습니다.
그것은 다른 일입니다. changelog는 짧고 선택적으로 작성할 수 있지만, 내부 기록 시스템은 완전하고 내구성이 있어야 합니다. 전문 소프트웨어 개발 및 실시간 업데이트 PIPELINE에서 세부적인 앱 버전 기록을 유지하려면, 각 버전의 '무엇', '언제', '누구'를 기록하여 책임성, 오류 복구, 빠른 롤백을 가능하게 해야 합니다. what, whenwho for every revision to enable accountability, error recovery, and rapid rollback, as described in this 이 버전 역사 정의 (ITU 온라인).
팀이 필요한 최소 기록
릴리스가 사용자에게 도달할 수 있다면, 기록 항목이 필요합니다. 최소한, 그 항목은 다음을 포함해야 합니다.
- 변경 사항: 스냅샷, 아티팩트 참조, 해시, 또는 diff 가능 패키지 식별자.
- 배포 시점: 정확한 배포 시간戳, 비 추상적인 릴리스 날짜가 아닌.
- 누가 트리거했는지: 이름이 지정된 개발자, 서비스 계정, 또는 CI 작업.
- 어디로 가는지: 제품, 베타, 스테이징, 또는 대상 고객 채널.
- 어떻게 되돌아가야 하는지: 이전 안정 버전과 롤백 경로.
실무 규칙: 팀이 배포할 수 있다면, 팀은 3개의 시스템을 검색하지 않고도 배포할 수 있는 버전을 식별하고 롤백할 수 있어야 한다.
성숙한 앱 버전 기록에도 불변성 필요하다. 팀은 노트를 추가할 수 있어야 하지만, 릴리즈 기록 자체를 수정하지 않아야 한다. 기록이 편집 가능한 방식으로 변하면, 사고 및 감사 시 유용하지 않게 된다.
4가지 이유로 앱이 현재 버전 기록을 필요로 한다.
버전 기록의 필요성은 추상적이지 않다. 지원 대기열, 사고 브리지, 준수 검토, 로드맵 결정에서 나타난다. 버전 기록을 생략하는 팀은 더 느린 협조 비용을 지불해야 한다.
사고 대응 속도가 빨라진다.
릴리즈가 잘못되면, 첫 번째 운영 과제는 버전 격리이다. 정확한 빌드 또는 패키지가 문제를 발생시켰는지, 어느 사용자에게 전달되었는지, 이전에 알려진 좋은 상태는 무엇인지?
버전 기록이 없으면 롤백은 토론이 된다. 버전 기록이 있으면 롤백은 결정이다. 엔지니어는 마지막 몇 개의 릴리즈를 검사하고, 타임스탬프를 비교하여, 문제가 발생한 업데이트를 식별하고, 안정적인 버전으로 이동하거나 사용자를 다시 이동할 수 있다.
이러한 속도는 모바일에서 더 중요하다. 스토어 수정이 시간이 걸리기 때문이다. 앱이 실시간 업데이트도 사용한다면, 내부 기록은 나쁜 패치를 확산시키지 않도록 멈추는 가장 빠른 방법이 된다.
감사 기록은 혼란이 사라진다
규제된 팀은 이미 이 고통을 알고 있습니다. 누군가가 프로덕션에서 변경된 증거, 승인자, 그리고 출시 일자를 요청할 때가 있습니다. 만약 릴리즈 데이터가 슬랙, Git 태그, CI 아티팩트, 그리고 앱 스토어 노트에 걸쳐 있다면, 답변은 너무 오래 걸리고 여전히 불완전합니다.
정확한 히스토리 시스템은 이 혼란을 쿼리로 바꿉니다. 특정 날짜 범위, 릴리즈 채널, 또는 기능 롤아웃에 대한 리비전 트레일을 pulls 할 수 있고, 일관된 기록을 보여줄 수 있습니다. 이는 규제가 필요하지 않지만, 규제에 구체적인 것을 검사할 수 있게 해줍니다.
지원팀은 버전별 이슈를 해결할 수 있습니다
지원팀은 raw 커밋 로그가 필요하지 않습니다. 사용자 보고서를 릴리즈 상태와 연결하는 신뢰할 수 있는 방법이 필요합니다.
일반적으로 다음과 같은 실제 질문에 답해야 합니다.
- 이 고객이 현재 스토어 버전을 사용하고 있는지 여부
- 그들은 최신 라이브 번들을 받았는지 여부
- 이 문제가 더 나은 리비전에서 이미 해결되었는지 여부
- 지원팀이 사용자에게 재시작, 업데이트, 또는 스테이지드 롤아웃을 기다리기를 묻아야 하는지 여부
지원팀과 엔지니어가 동일한 앱 버전 히스토리에서 읽을 때, escalations은 짧아지고 감정적인 것이 됩니다. 대화는 '우리가 생각한다'에서 '이 기기는 이 리비전에 있습니다'로 바뀝니다.
릴리즈 메커니즘과 모바일 업데이트 제어의 중요성에 대한 유용한 참고 자료는 이 내장 walkthrough에 나타납니다.
제품 및 엔지니어는 롤아웃 시각화에 접근할 수 있습니다
__CAPGO_KEEP_0__의 버전 기록은 오로지 긴급 상황에만 사용되는 것이 아니다. 또한 팀이 증거로써 릴리즈 결정을 내릴 수 있도록 도와준다.
Android은 버전 인식의 중요성을 보여주는 좋은 예이다. Android의 공개 버전 기록은 2007년 11월 5일에 출시된 베타 버전으로 시작된다. 2008년 9월 23일 에 출시된 Android 1.0이 최초의 상업 버전이다. 플랫폼은 현재 세계적으로 3억 개 이상의 활성 기기로 성장했다. 최신 주요 릴리즈는 2024년 에 출시된 Android 15이다. Android 14 도달 미국에서 2024년 중반까지 35%의 채택률, Android 11 인도에서 가장 퍼지게 된 Android 버전 28%의 채택률. Android는 일반적으로 1년에 한 번의 주요 업데이트 Android 버전 역사 참조에 따르면.
제품 및 엔지니어링에서, 그 종류의 분산화는 rollout 결정이 가정에 의존할 수 없다는 것을 의미합니다. 앱 버전과 OS 현실, 채널, 고객 집단에 대한 시각성을 필요로합니다. 그게 팀이 compatibility code를 폐기할 때, rollout을 늦추거나, 더 오래된 경로를 유지할 때의 결정입니다.
앱 스토어 히스토리 vs Live Update 히스토리
__CAPGO_KEEP_0__와 __CAPGO_KEEP_1__을 구분하는 문제가 다릅니다. 팀은 하나가 다른 것을 대체할 수 있다고 가정할 때 문제를 겪습니다.
스토어는 주요 바이너리 릴리스에 대한 공개 기록을 제공합니다. 그게 중요합니다. iOS에서 버전 기록은 원래 iPhone OS에서 2007년 6월 29일부터 시작되었으며 2024년 9월까지 iPhone OS 1에서 iOS 18까지 18개의 주요 버전을 거쳐 왔습니다. 2008년 7월 11일 iOS 2와 함께 App Store이 도착했으며 2013년 9월 18일 iOS 7은 주요 디자인 전환을 표시했습니다. 플랫폼은 전 세계적으로 1.5억 대의 활성 장치를 제공합니다. __CAPGO_KEEP_0__는 __CAPGO_KEEP_1__를 대체할 수 없습니다.__CAPGO_KEEP_0__는 __CAPGO_KEEP_1__를 대체할 수 없습니다. __CAPGO_KEEP_0__는 __CAPGO_KEEP_1__를 대체할 수 없습니다.__CAPGO_KEEP_0__는 __CAPGO_KEEP_1__를 대체할 수 없습니다. __CAPGO_KEEP_0__는 __CAPGO_KEEP_1__를 대체할 수 없습니다. __CAPGO_KEEP_0__는 __CAPGO_KEEP_1__를 대체할 수 없습니다. __CAPGO_KEEP_0__는 __CAPGO_KEEP_1__를 대체할 수 없습니다.__CAPGO_KEEP_0__는 __CAPGO_KEEP_1__를 대체할 수 없습니다. iOS 16 약 32%의 활성 iOS 기기 중 미국에서 2025년 초까지 32%의 활성 iOS 기기 중 미국에서 2025년 초까지이것에 따라 iOS 버전 역사 참조그 연례 주기는 원시 출시 계획에 유용한 맥락입니다.
그러나, 운영적으로, 스토어는 여전히粗한 타임라인입니다.
스토어의 역사
스토어 릴리스 역사
| Attribute | 앱 스토어 / 플레이 스토어 | 라이브 업데이트 플랫폼 (예: Capgo) |
|---|---|---|
| 대상 | 공개 및 파트너 대면 | 내부 엔지니어링, 지원 및 운영 |
| 릴리스 단위 | 자연어 바이너리 | 배포, 자산, 설정, 대상 패치 |
| 주기 | 제출 및 검토 흐름과 연관 | 배포 PIPELINE 속도에 따라 |
| 메타데이터 깊이 | 릴리스 중심으로 설계된 경우 운영 메타데이터 | 디테일한 운영 메타데이터 |
| 롤백 경로 | 일반적으로 다른 저장소 작업이 필요합니다. | 직접 이전 버전으로 되돌릴 수 있습니다. |
| 수사 | 마일STONE 추적에 좋습니다. | 사고 수준의 조사에 더 좋습니다. |
플랫폼 분산 바이너리, 승인, 공개 릴리스 노트와 같은 경우 저장소가 올바른 곳입니다. 제품 관리자와 외부 이해관계자는 그 기록을 필요로 합니다. 그것은 가시적이고 안정적이며 플랫폼 정책과 일치합니다.
라이브 업데이트 히스토리가 게임을 바칩니다.
팀이 자바스크립트, 자산, 복사본, 또는 구성 변경을 저장소 검토 경로 외부에서 배포한다면, 내부 버전 히스토리가 공개 릴리스 노트보다 더 중요합니다. 그곳에서 많은 모바일 PIPELINE이 현재 일상 생활을 합니다.
중요한 제한점은 API 깊이입니다. 공개 API 인 App Store Connect와 같은 경우 버전 히스토리를 노출할 수 있지만, 50개의 역사적 결과만 반환할 수 있는 제한을 가집니다. 이것은 완전한 장기 분석을 막고, 규정 준수 또는 수사 작업을 더 어렵게 만듭니다. 이것은 이에 대해 언급한 것과 같습니다. App Store Connect의 역사적 한계에 대한 토론입니다.그 한계가 팀이 내부 버전 추적을 구축하거나 채택하는 이유 중 하나입니다. 내부 버전 추적은 전체 버전 기록을 저장하고 채널 기반 배포를 지원합니다.
공개 API의 얕은 기록에 의존하는 사고 시간표가 있다면, 당신은 사고 시간표가 아니라 부분적인 기억만 가지고 있습니다.
실시간 업데이트 기록은 비공개, 검색 가능, granular해야 합니다. 이 기록은 차이 업데이트, 채널 대상, 배포 원본, 설치 상태, 롤백 관계를 보여줍니다. 또한, 다음의 운영 질문을 묻는 기능도 있어야 합니다: Beta 사용자에게만 보낸 프로덕션 핫픽스는 무엇인가? 마지막 네이티브 릴리스 이후에 배포된 자산만 변경한 것은 무엇인가? 마지막 안정 버전을 지원해야 하는 지원 버전은 무엇인가?
배달 모델을 평가하는 팀에게는 이 구분은 실용적이지요, 철학적이지 않습니다. 앱 스토어 업데이트와 직접 업데이트 비교 이 비교는 버전 기록 요구 사항을 형성하는 통치와 속도 상의 트레이드 오프를 강조하는 것이므로 검토할 가치가 있습니다.
버전 기록 데이터 모델을 설계하는 방법
효율적인 앱 버전 기록은 데이터 모델에서 시작해야 합니다. schema가 얕다면, 기록도 얕게 될 것입니다. 팀은 종종 버전 번호와 빌드 번호를 추적합니다. 채널, 패치, 롤백을 추가한 후에는 충분하지 않습니다.
일단부터 저장할 필드
버전 기록 모델은 일반적인 운영 질문을 쉽게 대답할 수 있어야 합니다. 이 필드는 대부분의 작업을 수행합니다:
- 버전 ID __CAPGO_KEEP_0__을 위한 고유한 내부 식별자입니다.
- __CAPGO_KEEP_0__ __CAPGO_KEEP_0__를 위한 사람이 읽을 수 있는 릴리즈 레이블입니다.
- __CAPGO_KEEP_0__ __CAPGO_KEEP_0__를 위한 네이티브 플랫폼 시퀀싱.
- __CAPGO_KEEP_0__ __CAPGO_KEEP_0__를 위한 프로덕션, 스테이징, 베타, 또는 고객 전용 롤아웃 스트림.
- __CAPGO_KEEP_0__ __CAPGO_KEEP_0__를 위한 정확한 배포 시간.
- __CAPGO_KEEP_0__ __CAPGO_KEEP_0__를 위한 개발자, 서비스 계정, 또는 CI PIPELINE이 릴리즈를 시작한 사람입니다.
- __CAPGO_KEEP_0__ 원본 추적을 위해 소스 제어에 대한 참조를 제공합니다.
- 릴리즈 노트 내부 컨텍스트에 대한 것만이 아니라 공공 마케팅 콘텐츠만이 아닌.
- 아티팩트 URL 바이너리 또는 번들 위치에 대한 것.
- 빠른 롤백 논리를 위해 버전 ID를 대체합니다. 상태
- draft, active, rolled back, retired, 또는 failed 상태를 나타냅니다. 사무실의 흰보드에서 복잡한 데이터베이스 엔터티 관계 다이어그램을 그리는 전문 개발자의 모습.
Capacitor version tagging in Capacitor apps 데이터 모델 자체와 함께 유용한 보완 요소입니다.
실제 JSON 예시
모바일 릴리스 작업을 대부분 커버하는 간단한 형태입니다:
{
"versionId": "ver_2025_02_18_prod_001",
"semanticVersion": "2.5.1",
"buildNumber": "42",
"platform": "ios",
"channel": "production",
"timestamp": "2025-02-18T14:22:00Z",
"author": "ci-release-bot",
"commitHash": "a1b2c3d4",
"releaseNotes": "Fixes login redirect loop and updates remote config defaults",
"artifactType": "live-bundle",
"artifactUrl": "bundle://releases/2.5.1",
"supersedesVersionId": "ver_2025_02_11_prod_004",
"status": "active",
"rollbackTarget": "ver_2025_02_11_prod_004",
"metadata": {
"storeBuild": "2.5.0",
"featureFlags": ["new-auth-flow"],
"audience": "all-users"
}
}릴리스 기록을 저장하십시오. 지원, 보안, 그리고 엔지니어링 모두가 같은 날에 그것을 필요로 할 것입니다. 결국, 그들은 그렇게 할 것입니다.
일관성이 중요합니다. 모든 릴리스 경로는 Xcode Cloud, GitHub Actions, Bitrise, Fastlane, 또는 커스텀 스크립트에서 오는 것과 같은 핵심 메타데이터를 모두 내보내야 합니다. 하나의 경로가 저자 식별 정보를 생략하고 다른 하나가 채널 정보를 생략한다면, 기록은 더 믿을 수 없게 됩니다.
Capgo를 사용한 실제 적용
버전 기록을 이해하는 가장 빠른 방법은 핫픽스 워크플로우를 살펴보는 것입니다.
릴리스 후 버그 리포트가 들어옵니다. 이슈는 생산 흐름에 영향을 미치지만, 이미 최근 웹 번들을 받은 기기만에 영향을 미칩니다. 엔지니어링은 처음에 넓은 회의를 필요로하지 않습니다. 그들은 필터된 리비전, 채널, 타임스탬프 목록이 필요합니다.
설명 가능한 핫픽스 워크플로우
라이브 업데이트를 설정한 경우, 개발자는 수정을 생성하고 CI는 새로운 번들을 빌드합니다. 시스템은 번들의 식별 정보, 배포 시간, 원본 작업, 그리고 대상 채널을 기록합니다. 팀은 채널별로 기록을 검사할 수 있습니다. 따라서, 변경이 최근 네이티브 제출의 일부인지, 나중에 패치의 일부인지 추측하지 않고 기록을 검사할 수 있습니다.
그것이 __CAPGO_KEEP_0__와 같은 도구의 역할입니다. Capgo fits. It provides bundle history for Capacitor apps, tracks updates by channel, and supports rollback-oriented workflows for teams shipping outside store review. This overview of Capgo은 버전 관리와 롤백을 어떻게 처리하는지에 대해 알려줍니다. 모바일 팀이 자주 업데이트를 푸시하기 시작하면 일반적으로 필요한 운영 모델의 종류를 보여줍니다.
릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재구축하는 데 시간이 없기 때문에 로그의 원본 상태에서 릴레이션 상태를 재
롤백을 쉽게 하세요
버전 관리 흐름이 좋은 것은 "어떤 버전을 시도해야 하나?"라는 질문으로 시작하지 않는다. 좋은 버전 관리 흐름은 이전에 안정적인 릴리스가 명확한 visible한 변경 내역의 chain으로 시작한다.
이것은 사건 대응의 품질을 몇 가지 구체적인 방법으로 바꿉니다.
- 개발에 확신이 생기고 있습니다: 팀은 정확한 핫픽스 후보와 그 전작을 식별할 수 있습니다.
- 지원은 스크립트를 받습니다: 유저들이 다시 시작해야 하는지 또는 단계별로 수정待ち인지 설명할 수 있습니다.
- 제품이 포함된 범위: 관련자들은 이슈가 하나의 채널이나 릴리즈 웨이브에만 국한되어 있는지 여부를 볼 수 있습니다.
이것도 사후 분석을 개선합니다. 이슈가 패치로 인해 발생했는지에 대한 팀의 의견 대신, 다음 순서를 지시할 수 있습니다: 네이티브 빌드 승인, 라이브 번들 배포, 오류 보고, 롤백 트리거, 안정 번들 복원. 그 정도의 추적성은 앱 버전 기록을 관리에서 릴리즈 제어로 바꾸는 것입니다.
기록 관리에서 릴리즈 제어로
앱 버전 기록은 일반적으로 문서로 간주됩니다. 숙련된 팀은 이를 운영 제어 표면으로 다룹니다.
이 변화를 중요하게 여기는 이유는 모바일 배포가 이제 두 개의 시계에 따라 작동하기 때문입니다. 첫 번째는 스토어 시계로, 네이티브 바이너리, 공개 릴리즈, 검토 기반 일정과 관련이 있습니다. 두 번째는 라이브 업데이트 시계로, 빠른 수정, 대상 롤아웃, 롤백 속도와 관련이 있습니다. 만약 첫 번째만 추적한다면, 가장 빠르게 움직이는 순간에 눈이 멀게 됩니다.
강력한 기록 시스템은 지원 팀에게 신뢰할 수 있는 답변, 제품 팀에게 실제 롤아웃 그림, 그리고 엔지니어 팀에게 안전한 상태로 돌아가기 위한 안전한 경로를 제공합니다. 또한 릴리즈에 대한 일반적인 두려움을 제거합니다: 사용자가 실행 중인 정확한 버전을 알지 못하는 것입니다.
현재 릴리즈 PIPELINE을 검토하세요. 다음 질문 하나만 생각하세요. 다음 시간에 프로덕션에 문제가 발생하면, 팀이 나쁜 리비전을 식별하고 역전할 수 있을까요? 검색하는 동안 여러 도구를 사용하지 않아도 되나요? 만약 '아니오'라고 답한다면, 버전 기록이 개선이 필요합니다.
Capgo는 Capacitor 팀이 버전 기록을 릴리스 작업의 일부로 다루는 대신 릴리스 노트로만 다루는 것을 도와줍니다. 채널 기반 실시간 업데이트, 패키지 기록, 롤백 지원이 같은 워크플로우에서 필요하다면看看해 보세요. Capgo.
