릴리스가 늦은 밤에 나간다. 지원 팀이 잠에서 깨서 충돌 신고, 로그인 실패, 또는 suddenly 중단 된 체크아웃 흐름에 대해 신고를 받는다. 엔지니어링 팀은 첫 번째로 물어보는 질문이 무엇인지 물어본다. 그리고 방은 조용해진다.
Git 커밋을 pull하는 한 사람. 다른 사람들은 CI 로그를 스캔한다. 제품은 App Store 릴리스 노트를 확인한다. 그러나 그것은
모바일 팀이 스토어를 통해 배포하고 code도 스토어 리뷰 경로 외부에 푸시한다면, 버전 기록을 시스템으로 다루지 않는 한 운영 위험은 두 배로 증가합니다. 리뷰 지연, 제출 거부, 또는 출시 기원 불명이 있는 팀은 이 패턴을 인식할 것입니다. 앱 스토어 거부 사후 분석. 버전 상태가 불분명할 때, 속도가 가장 중요할 때 인시던트 리스폰스 속도가 느려지게 됩니다.
목차
- 버전 기록이 중요해지는 순간
- 버전 기록이 정말 무엇인가요
- 4가지 이유로 앱이 현재 버전 기록을 필요로 합니다
- 앱 스토어 히스토리 vs 라이브 업데이트 히스토리
- 버전 히스토리 데이터 모델을 설계하는 방법
- 실무에 적용하는 방법: Capgo
- 버전 기록 관리에서 릴리스 제어로
버전 기록의 중요성이란 무엇인가?
버그 자체가 아니라 버그를 발견하고 정확한 릴리스를 식별하는 시간 차이가 문제다.
모바일 팀은 결함을 견딜 수 있지만 불확실성이 시간을 소비한다. 릴리스가 승인된 바이너리, 배포된 패키지, 받은 채널, 변경을 트리거한 사람을 알 수 없다면, 매 분가는 고고학이 된다. 개발자들은 커밋 메시지를 검색하고, 지원 팀은 스크린샷을 전달한다. 제품 팀은 이슈가 모든 사용자에게 영향을 미치는지 아니면 특정 세그먼트만에 미치는지 물어본다. nobody가 단일 운영 기록을 가지고 있지 않다.
압박을 받으면 운영 기록의 약점이 나타난다.
릴리스 기록을 저장하면 공공 마일STONE을 제공한다. 버전이 존재했다는 것을 알려준다. 일반적으로 내부 이벤트의 시퀀스에 대한 충분한 정보를 제공하지 않는다. 현대 모바일 배포에서, 그것은 심각한 약점이다. 왜냐하면 앱 사용자는 종종 여러 층으로 구성된 결과를 실행한다: 네이티브 바이너리, 웹 패키지, 자산, 기능 플래그, 구성.
공개 릴리스 노트는 고객에게 도움이 된다. 그러나 사고 시에는 도움이 되지 않는다.
이 문제를 잘 해결하는 팀은 기억이나 흩어져 있는 도구에 의존하지 않는다. 릴리스 가능한 모든 아티팩트를 시간대, 원본, 목적지 채널과 연결하는 버전 기록을 유지한다. 사고가 시작되면, 그들은 역사를 재구성하는 것이 아니라 읽고 있다.
역사가 약해질 때 발생하는 문제
version history가 약해질 때 발생하는 chain of avoidable problems:
- 버전 롤백이 지연됩니다: 팀은 마지막으로 잘 알려진 버전을 결정하기 위해 토론합니다.
- 지원이 정확도가 떨어집니다: agent는 보고서가 이전 빌드의 스토어 또는 최신 라이브 패치에 속하는지 알 수 없습니다.
- 사후 분석이 흐릿합니다: Regression이 있었지만 정확한 릴리스 순서를 증명할 수 없습니다.
- 내부 신뢰가 약화됩니다: 제품, 지원 및 엔지니어는 “현재 버전”에 대한 동일한 언어를 사용하지 않습니다.
그것은 관리 작업이 아니며 생산 제어입니다.
App Version History는 무엇입니까?
App Version History는 해당 앱의 모든 배포된 애플리케이션의 Git 히스토리입니다., repository만 아니라 code 또는 자산이 변경되었는지, 언제 변경되었는지, 누가 릴리즈를 시작했는지, 그리고 릴리즈가 어디로 향했는지 알려줘야 합니다. 앱이 스토어 제출 외에서 변경될 수 있다면, 앱의 역사도 같은 엄격성을 가지고 이러한 변경 사항을 캡처해야 합니다.
앱 버전 역사에 대한 많은 팀들이 마케팅 artifact로 다루고 있습니다. 그게 너무 좁습니다. 올바른 시스템은 바이너리, 자바스크립트 번들, 자산, 구성 변경, 릴리즈 채널, 릴리즈 메타데이터를 하나의 감사 가능한 기록에 기록합니다. 만약 배포 모델을 비교한다면, 이 구분은 traditional versioning과 OTA 업데이트 사이의 간격의 핵심입니다. traditional versioning and OTA updates in Capacitor.
변경 로그는 사용자에게, 역사 시스템은 운영자에게 있습니다.
사용자에게는 '무엇이 새로운가?'가 답입니다. 운영자에게는 '무엇이 정확히 배포되었는지, 언제, 누구에 의해, 그리고 어떻게 그것을 되돌릴 수 있는가?'가 답입니다.
그것은 다른 일입니다. 변경 로그는 짧고 선택적으로 할 수 있습니다. 내부 역사 시스템은 완전하고 내구성이 있어야 합니다. 전문 소프트웨어 개발 및 실시간 업데이트 PIPELINE에서 앱 버전 역사에 대한 세부 정보를 유지하려면, what, when, who 모든 변경 사항을 캡처하여 책임성, 오류 복구, 빠른 롤백을 위한 계좌를 유지할 수 있도록 하기 위해, 이에 대한 설명이 있습니다. 버전 역사 정의 (ITU Online).
팀이 필요한 최소 기록
사용자에게 릴리스가 도달할 수 있다면, 그 릴리스에 대한 기록이 필요합니다. 최소한, 그 기록에는 다음과 같은 정보가 포함되어야 합니다.
- 변경된 내용: 스냅샷, 아티팩트 참조, 해시, 또는 diff 가능한 번들 식별자.
- 배포된 시점: 정확한 배포 시간戳, 비슷한 릴리스 날짜가 아닌.
- 누가 트리거했는가: 이름이 있는 개발자, 서비스 계정, 또는 CI 작업.
- 어디로 가는가: 제품, 베타, 스테이징, 또는 특정 고객 채널.
- 어떻게 되돌아가야 하는가: 이전 안정 버전과 롤백 경로.
실용적인 규칙: 팀이 배포할 수 있다면, 팀은 3개의 시스템을 검색하지 않고도 버전을 식별하고 롤백할 수 있어야 한다.
성숙한 앱 버전 기록도 불변성 필요하다. 팀은 주석을 추가할 수 있지만, 릴리스 기록 자체를 수정해서는 안된다. 기록이 편집 가능한 방식으로 변하면, 사고 및 감사 시 유용하지 않게 된다.
네 가지 이유로 앱이 현재 버전 기록을 필요로 한다.
앱 버전 기록의 논리는 추상적이지 않다. 지원 대기열, 사고 브리지, 준수 검토, 로드맵 결정에 나타난다. 버전 기록을 생략하는 팀은 느린 협조 비용을 지불해야 한다.
사고 대응 속도가 빨라진다.
릴리스가 잘못되면, 첫 번째 운영 작업은 버전 격리이다. 정확한 빌드 또는 패키지가 문제를 발생시켰는지, 어느 사용자에게 전달되었는지, 이전에 알려진 좋은 상태는 무엇인지?
역사가 없으면 롤백은 토론이 된다. 역사가 있으면 롤백은 결정이다. 엔지니어는 마지막 몇 개의 릴리스를 검사하고, 타임스탬프를 비교하여, 문제가 발생한 업데이트를 식별하고, 안정적인 버전으로 이동하거나 사용자를 이동할 수 있다.
이러한 속도는 모바일에서 더 중요하다. 스토어의 수정이 시간이 걸리기 때문이다. 앱이 실시간 업데이트도 사용한다면, 내부 역사가 가장 빠른 방법으로 나쁜 패치를 막을 수 있다.
감사 기록은 혼란이 사라진다.
관리되는 팀은 이미 이 고통을 알고 있습니다. 누군가가 프로덕션에서 변경된 증거를 요청하고, 승인자와 언제 출시되었는지 물어볼 것입니다. 만약 릴리스 데이터가 슬랙, Git 태그, CI 아티팩트 및 앱 스토어 노트에 걸쳐 있다면, 답변이 너무 오래 걸리고 여전히 불완전한 느낌이 들 것입니다.
적절한 역사 시스템은 이러한 혼란을 쿼리로 바꿉니다. 특정 날짜 범위, 릴리스 채널 또는 기능 출시에 대한 리비전 트레일을 pulls 할 수 있고, 일관된 기록을 보여줄 수 있습니다. 이는 관리에 대한 필요성을 제거하지는 않지만, 관리에 구체적인 것을 검사할 수 있게 해줍니다.
지원팀은 버전별 문제를 해결할 수 있습니다
지원팀은 raw 커밋 로그가 필요하지 않습니다. 사용자 보고서를 릴리스 상태와 연결하는 신뢰할 수 있는 방법이 필요합니다.
일반적으로 다음과 같은 실용적인 질문에 답해야 합니다:
- 이 고객이 현재 스토어 버전인지 확인할 수 있나요?
- 그들은 최신 라이브 번들을 받았는지 확인할 수 있나요?
- 이 문제가 이미 더 나은 리비전에서 해결되었는지 확인할 수 있나요?
- 지원팀은 사용자에게 다시 시작하거나 업데이트하거나 스테이지드 롤아웃을 기다리기를 묻아야 하나요?
지원팀과 엔지니어가 동일한 앱 버전 역사에서 읽을 때, escalations이 짧아지고 감정적인 것이 줄어듭니다. 대화는 '우리는 생각한다'에서 '이 장치가 이 리비전에 있습니다'로 바뀝니다.
릴리스 메커니즘에 대한 유용한 참고 자료와 모바일 업데이트 제어의 중요성에 대한 이유가 이MBEDDED Walkthrough에 나타납니다:
제품 및 엔지니어는 롤아웃 시각성을 얻습니다
버전 기록은 비상 사태에만 사용되는 것이 아니다. 또한 팀이 증거로써 릴리즈 결정을 내릴 수 있도록 도와준다.
안드로이드는 버전 인식의 중요성을 보여주는 좋은 예이다. 안드로이드의 공개 버전 기록은 2007년 11월 5일에 시작되었으며 2008년 9월 23일 에 첫 번째 상업 버전 안드로이드 1.0이 출시되었다. 이 플랫폼은 현재 세계적으로 억 개 이상의 활성 장치로 성장했다. 최근 주요 릴리즈는 2024년 안드로이드 15 안드로이드 14 도달 미국에서 2024년 중반까지 35%의 채택, 반면 안드로이드 11 인도에서 가장 퍼지게 된 것으로 나타났습니다. 28%의 채택. 안드로이드는 일반적으로 1년에 한 번의 주요 업데이트를 제공합니다. 안드로이드 버전 역사 참조에 따르면.
제품 및 엔지니어링에서, 이러한 분산은 롤아웃 결정이 가정에 의존할 수 없다는 것을 의미합니다. 앱 버전과 OS 현실, 채널, 고객 그룹에 대한 시각성을 필요로합니다. 그들은 호환성을 지원하는지, 롤아웃을 늦추는지, 또는 더 오래된 경로를 유지해야 하는지 결정하기 때문입니다. code
앱 스토어 역사 vs Live Update 역사
스토어의 역사와 라이브 업데이트 기록은 서로 다른 문제를 해결합니다. 팀은 한 가지가 다른 것을 대체할 수 있다고 가정할 때 문제를 겪습니다.
스토어는 주요 바이너리 릴리스에 대한 공개 기록을 제공합니다. 그게 중요합니다. iOS에서 버전 기록은 원래 아이폰 OS에서 2007년 6월 29일 시작하여 2024년 9월까지 아이폰 OS 1에서 iOS 18까지 18개의 주요 버전을 거쳐 왔습니다. 2007년 6월 29일 그리고 18개의 주요 버전을 거쳐아이폰 OS 1에서 iOS 18까지 2024년 9월까지iOS 2는 2008년 7월 11일에 도착했으며 iOS 7는 2013년 9월 18일에 도착했으며 디자인 전환을 포함한 주요 디자인 전환을 표시했습니다. 플랫폼은 전 세계적으로 1.5억 대의 활성 장치를 제공합니다.그리고 iOS 16 약 32%의 활발한 iOS 기기 중 미국에서 2025년 초까지의에 따르면 iOS 버전 역사 참조. 이 연간 주기는 원시 릴리스 계획에 유용한 배경 정보입니다.
그러나 실제로 운영은 여전히粗한 시간선입니다.
Store의 역사적인 부분은
Store 릴리스 역사에는 몇 가지 좋은 점이 있습니다:
| 속성 | App Store / Play Store | Live Update Platform (e.g., Capgo) |
|---|---|---|
| 대상 | 공개 및 파트너 대면 | 내부 엔지니어링, 지원 및 운영 |
| 릴리스 단위 | 네이티브 바이너리 | 번들, 자산, 설정, 대상 패치 |
| 주기 | 제출 및 검토 흐름과 연관 | 배포 PIPELINE의 속도에 따라 |
| 메타데이터 깊이 | 제한된 릴리스 지향적 맥락 | 디자인된 경우 자세한 운영 메타데이터 |
| 되돌리기 경로 | 일반적으로 다른 저장소 작업이 필요합니다 | 직접 이전 버전으로 되돌릴 수 있습니다 |
| 수사 | 마일스톤 추적에 좋습니다 | 사고 수준의 조사에 더 좋습니다 |
플랫폼 분배 바이너리, 승인, 공개 릴리즈 노트와 같은 경우 저장소가 올바른 곳입니다. 제품 매니저와 외부 이해관계자는 그 기록이 필요합니다. 그것은 가시적이고 안정적이며 플랫폼 정책과 일치합니다.
라이브 업데이트 히스토리가 게임을 바칩니다
팀이 자바스크립트, 자산, 복사본, 또는 구성 변경을 저장소 검토 경로 외부에서 배포한다면, 내부 버전 히스토리가 공개 릴리즈 노트보다 더 중요합니다. 그곳은 많은 모바일 PIPELINE이 일상적으로 살고 있습니다.
중요한 제한은 API 깊이입니다. 공개 API 인 App Store Connect와 같은 경우 버전 히스토리를 노출할 수 있지만, 50개의 역사적 결과만 노출할 수 있습니다. 이것은 완전한 장기 분석을 막고, 규정 준수 또는 수사 작업을 더 어렵게 만듭니다.이것은 이 애플리케이션 스토어 연결의 역사적 한계에 대한 토론그 한계는 팀이 내부 버전 추적을 구축하거나 채택하여 전체 수정 역사와 채널 기반 배포를 지원하는 이유 중 하나입니다.
공개 API에 얕은 역사에 의존하는 인시던트 타임라인이 있다면, 당신은 인시던트 타임라인이 아니라 부분적인 기억만 가지고 있습니다.
라이브 업데이트 역사에는 privaye, searchable, granular해야 합니다. 이력은 차이 업데이트, 채널 타겟팅, 배포 원인, 설치 상태, 롤백 관계를 보여줘야 합니다. 또한, 다음의 운영 질문을 할 수 있어야 합니다: beta 관객에게 먼저 보낸 프로덕션 핫픽스는 무엇인가? 마지막 네이티브 릴리스 이후에 배포된 자산만 변경한 것은 무엇인가? 마지막 안정 버전을 지원해야 하는 수정은 무엇인가?
배포 모델을 평가하는 팀에게는 이 차이점은 실용적이지요, 철학적이지 않습니다. 애플리케이션 스토어 업데이트와 직접 업데이트 비교 이 비교는 버전 역사 요구 사항을 형성하는 통치와 속도 상의 트레이드 오프를 강조하기 때문에 검토할 가치가 있습니다.
버전 역사 데이터 모델을 설계하는 방법
유용한 애플리케이션 버전 역사에는 데이터 모델이 필요합니다. schema가 얕다면, 역사도 얕게 될 것입니다. 팀은 일반적으로 버전 번호와 빌드 번호를 추적합니다. 채널, 패치, 롤백을 추가한 후에는 충분하지 않습니다.
일찍부터 저장할 수 있는 필드
버전 모델은 일반적인 운영 질문을 쉽게 답변할 수 있어야 합니다. 이 필드는 대부분의 작업을 수행합니다:
- 버전 ID 유니크한 내부 식별자로 변경되지 않는 식별자입니다.
- Semantic Version 인간이 읽을 수 있는 릴리즈 레이블입니다.
- 빌드 번호 자연 플랫폼 시퀀싱을 위해.
- 채널 제품, 스테이징, 베타, 또는 고객 전용 롤아웃 스트림을 위해.
- 타임스탬프 정확한 배포 시간을 위해.
- 개발자, 서비스 계정, 또는 CI PIPELINE이 릴리즈를 시작한 사람입니다. 커밋 해시
- Semantic Version 원본 추적을 위해 소스 제어에 대한 참조를 제공합니다.
- 릴리즈 노트 내부 컨텍스트에 대한 것만 아니라, 공개 마케팅 콘텐츠도 아닌 것입니다.
- 아티팩트 URL 바이너리 또는 번들의 위치를 위한 것입니다.
- 빠른 롤백을 위한 버전 ID입니다. 상태
- 개발자가 복잡한 데이터베이스 엔터티 관계 다이어그램을 백보드에 그리는 모습입니다. 하이브리드 앱의 이름과 릴리즈 식별자에 대한 작업을 하고 있다면, 이 __CAPGO_KEEP_0__ 앱 버전 태깅에 대한 안내서를 참조하세요.
status: active version tagging in Capacitor apps 데이터 모델 자체에 유용한 보완 요소입니다.
A practical JSON example
다음과 같은 간단한 모바일 릴리스 작업을 위한 형태를 사용하세요:
{
"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. Capacitor은 앱 버전의 역사 기록을 제공하고 채널을 통해 업데이트를 추적하며, 스토어 리뷰 외에 팀이 배포하는 경우 롤백 지향 워크플로를 지원합니다. 이 Capacitor이 버전 관리 및 롤백을 처리하는 방식에 대한 개요는 Capgo이 버전 관리 및 롤백을 처리하는 방식에 대한 개요입니다. 이것은 모바일 팀이 자주 업데이트를 푸시하기 시작한 후에 일반적으로 필요한 운영 모델의 종류를 보여줍니다.
대시보드 화면은 중요합니다. 이는 로그의 원본 상태를 재구성하는 데 시간이 걸리는 응답자들이 있기 때문입니다.
예상치 못한 롤백
좋은 롤백 흐름은 '어떤 버전을 시도해야 하나?'라는 질문으로 시작하지 않습니다. 이전에 안정적인 릴리스가 명확한 변경 사항의 체인에서 시작합니다.
이것은 몇 가지 구체적인 방식으로 사고 대응의 품질을 바꿉니다:
- 엔지니어링은 확신을 얻습니다: 팀은 정확한 핫픽스 후보와 그 전의 버전을 식별할 수 있습니다.
- 지원 팀은 스크립트를 받습니다: -agent는 영향을 받은 사용자가 다시 출시할 필요가 있는지 또는 단계별로 수정을 기다리는 중인지 설명할 수 있습니다.
- 제품이 포함되기 시작합니다: 유관사들은 문제가 한 채널이나 릴리즈 웨이브에만 국한되어 있는지 여부를 확인할 수 있습니다.
이것은 사후 분석을 개선합니다. 팀이 '패치가 문제를 일으켰다고 믿는다'고 말하는 대신, 다음 순서를 지적할 수 있습니다: 네이티브 빌드 승인, 라이브 번들 배포, 오류 보고, 롤백 트리거, 안정 번들 복원. 그 정도의 추적성은 앱 버전 기록을 책임 관리에서 릴리스 관리로 바꾸는 것입니다.
기록 관리에서 릴리스 관리로
앱 버전 기록은 일반적으로 문서화로 간주됩니다. 숙련된 팀은 이를 운영 관리 표면으로 다룹니다.
이러한 변화는 모바일 배포가 현재 두 개의 시계에 달려 있습니다. 첫 번째는 스토어 시계로, 네이티브 바이너리, 공개 릴리스, 검토 기반의 리듬을 다룹니다. 두 번째는 라이브 업데이트 시계로, 빠른 수정, 대상 롤아웃, 롤백 속도를 다룹니다. 만약 첫 번째만 추적한다면, 가장 빠르게 움직이는 순간에 눈이 멀게 됩니다.
강력한 기록 시스템은 지원 팀에게 신뢰할 수 있는 답변, 제품 팀에게 실제 론칭 그림, 엔지니어링 팀에게 알려진 좋은 상태로 돌아가기 위한 안전한 경로를 제공합니다. 또한 릴리스에 대한 두려움의 근원인 '사용자가 현재 어떤 버전을 실행하고 있는지 정확히 알지 못한다'는 문제를 제거합니다.
현재 릴리스 PIPELINE을 검토하세요. 다음 질문 하나만 생각하세요. 다음 시간에 프로덕션에 문제가 발생하면, 팀이 나쁜 리비전을 식별하고 역전할 수 있는지 여부를 확인할 수 있나요? 만약 '아니오'라면, 버전 기록이 개선이 필요합니다.
Capgo는 Capacitor 팀이 버전 기록을 릴리스 작업의 일부로, 릴리스 노트만으로 다루지 않도록 도와줍니다. channel-based live updates, bundle history, rollback support를 같은 워크플로우에서 지원하려면看看 Capgo.
