마틴 도나디우
콘텐츠 마케터: 앱 버전 역사 - 개발자 가이드 - 더 나은 릴리스를 위해
모바일 팀이 스토어를 통해 배포하고 스토어 리뷰 경로 외부에 code를 푸시한다면, 버전 기록을 시스템으로 다루지 않는 한 운영 위험은 두 배로 증가합니다. 리뷰 지연, 제출 거부, 또는 릴리스 출처가 불분명한 문제를 겪은 팀은 이 패턴을 인식할 것입니다. 앱 스토어 거부 사후 분석.
배포 상태가 불분명할 때, 속도가 가장 중요할 때 인시던트 리스폰스 속도가 느려지게 됩니다.
- 목차
- 버전 기록이 약해질 때 무엇이 깨지나요?
- 팀이 필요한 최소한의 기록
- __CAPGO_KEEP_3__
- __CAPGO_KEEP_6__
- Putting It into Practice with Capgo
- 릴리스 관리에서 제어권까지
버전 기록의 중요성을 깨닫는 결정적 순간
실패는 버그 자체가 아니라 버그를 보고 버그를 정확히 식별하는 시간 차이 때문이다.
모바일 팀은 결함을 견딜 수 있다. 시간을 소모하는 것은 불확실성이다. 만약에 승인된 바이너리, 전달된 패키지, 받은 채널, 변경을 트리거한 사람을 알 수 없다면, 매 분마다 고고학이 된다. 개발자들은 커밋 메시지를 검색한다. 지원 팀은 스크린샷을 전달한다. 제품 팀은 이슈가 모든 사용자에게 영향을 미치는지 아니면 특정 세그먼트만에 미치는지 물어본다. nobody가 단일 운영 기록을 가지고 있지 않다.
압박을 받을 때 운영적 결핍이 나타난다
릴리스 기록을 저장하면 공공 마일STONE을 제공한다. 버전이 존재했음을 알려준다. 일반적으로 내부 이벤트의 시퀀스에 대한 충분한 정보를 알려주지 않는다. 현대 모바일 전달에서 이것은 심각한 결핍이다. 왜냐하면 앱 사용자는 종종 여러 층으로 구성된 결과를 실행한다: 네이티브 바이너리, 웹 번들, 자산, 기능 플래그, 구성.
공개 릴리스 노트는 고객에게 도움이 된다. 그러나 사고 중에 응답자에게 도움이 되지 않는다.
이것을 잘 처리하는 팀은 기억이나 산재된 도구에 의존하지 않는다. 그들은 각 배포 가능한 아티팩트를 시간대, 원천, 목적 채널과 연결하는 버전 일지를 유지한다. 사고가 시작될 때, 그들은 역사를 재구성하는 것이 아니라 읽고 있다.
역사가 약해질 때 무엇이 깨지나
약한 앱 버전 기록 시스템은 다음의 chain된 문제를 발생시킨다:
- __CAPGO_KEEP_0__ 지연되었습니다: __CAPGO_KEEP_1__ 팀은 마지막으로 잘 알려진 버전을 결정하기 위해 토론합니다.
- __CAPGO_KEEP_0__ 지원이 정확도가 떨어집니다: __CAPGO_KEEP_1__ 에이전트는 보고서가 이전에 빌드된 저장소 또는 최신 라이브 패치에 속하는지 알 수 없습니다.
- __CAPGO_KEEP_0__ 사후 분석은 흐릿합니다: __CAPGO_KEEP_1__ regression이 있었지만 정확한 릴리스 순서를 증명할 수 없습니다.
- __CAPGO_KEEP_0__ 내부적으로 신뢰가 약화됩니다: __CAPGO_KEEP_1__ 제품, 지원 및 엔지니어는 “현재 버전”에 대한 동일한 언어를 사용하지 않습니다.
__CAPGO_KEEP_0__ 그 이유는 이것이 관리 작업이 아니라는 것입니다. 그것은 생산 제어입니다.
__CAPGO_KEEP_1__ App 버전 기록이 무엇인가요.
__CAPGO_KEEP_0__ App 버전 기록은 __CAPGO_KEEP_1__ shipped 애플리케이션의 전체 Git 기록입니다code 이외의 저장소만 아니라 code 또는 자산이 변경된 것을 알려주고, 언제 변경되었는지, 누가 릴리즈를 시작했는지, 그리고 릴리즈가 어디로 향했는지 알려줘야 합니다. 앱이 스토어 제출 외에서 변경될 수 있다면, 그 변경 사항을 native 빌드와 같은 엄격함으로 기록해야 합니다.
많은 팀이 버전 히스토리를 마케팅 자료로 다루고 있습니다. 그게 너무 좁습니다. 올바른 시스템은 하나의 감사 가능한 기록에서 바이너리, 자바스크립트 번들, 자산, 설정 변경, 롤아웃 채널, 릴리즈 메타데이터를 기록해야 합니다. 만약 배포 모델을 비교한다면, 이 구분은 __CAPGO_KEEP_0__와 OTA 업데이트 사이의 간극의 핵심입니다. traditional versioning and OTA updates in Capacitor.
사용자에게는 '무엇이 새로운가?'를 알려주는 릴리즈 노트가 있습니다. 운영자는 '무엇이 정확히 배포되었고, 언제, 누구에 의해, 그리고 어떻게 그것을 되돌릴 수 있는가?'를 알고 싶습니다.
그것은 다른 일입니다. 변경 로그는 짧고 선택적으로 할 수 있습니다. 내부 히스토리 시스템은 완전하고 내구성이 있어야 합니다. 전문적인 소프트웨어 개발과 실시간 업데이트 PIPELINE에서 앱 버전 히스토리를 자세히 유지하려면, 각 리비전의 '무엇', '언제', '누구'를 캡처하여 책임성, 오류 복구, 빠른 롤백을 가능하게 해야 합니다. 이는 이 설명서에서 설명한 바와 같습니다.
what when, whofor every revision to enable accountability, error recovery, and rapid rollback, as described in this traditional versioning and OTA updates in __CAPGO_KEEP_0__ A lot of teams still treat version history as a marketing artifact. That’s too narrow. A proper system records binaries, JavaScript bundles, assets, config changes, rollout channels, and release metadata in one auditable trail. If you’re comparing delivery models, this distinction is the heart of the gap between version history definition from ITU Online.
팀이 필요한 최소 기록
릴리스가 사용자에게 도달할 수 있다면, 기록 항목이 필요합니다. 최소한, 그 항목에는 다음이 포함되어야 합니다.
- 변경 사항: 스냅샷, 아티팩트 참조, 해시, 또는 diff 가능 패키지 식별자.
- 배포 시점: 정확한 배포 시간戳, 비슷한 릴리스 날짜가 아닌.
- 릴리스를 트리거한 사람: 이름이 있는 개발자, 서비스 계정, 또는 CI 작업.
- 배포 대상: 제품, 베타, 스테이징, 또는 특정 고객 채널.
- 릴리스를 취소하는 방법: The previous stable revision and rollback path.
실무 규칙: If your team can deploy it, your team must be able to identify it and revert it without searching three systems.
성숙한 앱 버전 기록도 불변성 필요합니다. 팀은 노트를 추가할 수 있어야 하지만, 그들은 릴리스 기록 자체를 수정하지 않아야 합니다. 기록이 편집 가능한 방식으로 변하면, 사고 및 감사 시 유용하지 않게 됩니다.
네 가지 이유로 앱이 현재 버전 기록을 필요로 합니다.
버전 기록의 필요성은 추상적인 논쟁이 아닙니다. 지원 대기열, 사고 브리지, 준수 검토, 로드맵 결정에서 나타납니다. 버전 기록을 생략하는 팀은 더 느린 협조 비용을 지불합니다.
사고 대응 속도가 빨라집니다.
릴리스가 잘못되면, 첫 번째 운영 작업은 버전 분리입니다. 정확한 빌드 또는 패키지가 문제를 발생시켰는지, 어떤 사용자에게 전달되었는지, 이전에 알려진 좋은 상태는 무엇인지.
버전 기록이 없으면, 롤백은 토론이 됩니다. 버전 기록이 있으면, 롤백은 결정이 됩니다. 엔지니어는 마지막 몇 개의 릴리스를 검사하고, 타임스탬프를 비교하여, 의심스러운 업데이트를 식별하고, 트래픽 또는 사용자를 안정적인 버전으로 되돌리십시오.
이러한 속도는 모바일에서 더 중요합니다. 스토어 수정이 시간이 걸릴 수 있기 때문입니다. 앱이 실시간 업데이트도 사용한다면, 내부 기록은 나쁜 패치를 퍼뜨리지 않도록 멈추는 가장 빠른 방법이 됩니다.
감사 기록은 혼란이 사라집니다.
관리되는 팀은 이미 이 고통을 알고 있습니다. 누군가가 프로덕션에서 변경된 증거, 승인자, 그리고 출시 일자를 요청할 때가 있습니다. 만약 릴리스 데이터가 슬랙, Git 태그, CI 아티팩트, 그리고 앱 스토어 노트에 걸쳐 있다면, 답변은 너무 오래 걸리고 여전히 불완전합니다.
적절한 역사 시스템은 이 혼란을 쿼리로 바꿉니다. 특정 날짜 범위, 릴리스 채널, 또는 기능 롤아웃에 대한 변경 사항의 추적 기록을 pulls 할 수 있고, 일관된 기록을 보여줄 수 있습니다. 이는 관리를 제거하는 것은 아니지만, 관리가 검토할 수 있는 구체적인 내용을 제공합니다.
지원은 버전별 문제를 해결할 수 있습니다
지원은 raw 커밋 로그가 필요하지 않습니다. 사용자 보고서를 릴리스 상태와 연결하는 신뢰할 수 있는 방법이 필요합니다.
일반적으로 다음과 같은 실용적인 질문에 대답해야 합니다:
- 이 고객이 현재 스토어 버전을 사용하고 있는지 여부
- 그들은 최신 라이브 번들을 받았는지 여부
- 이 문제가 이후 버전에서 이미 해결되었는지 여부
- 지원이 사용자에게 재시작, 업데이트, 또는 스테이지드 롤아웃을 기다리기를 요청해야 하는지 여부
지원과 엔지니어링이 동일한 앱 버전 역사에서 읽을 때, escalations은 짧아지고 감정적인 것이 됩니다. 대화는 '우리가 생각한다'에서 '이 기기는 이 버전입니다'로 바뀝니다.
릴리스 메커니즘에 대한 유용한 참고 자료와 모바일 업데이트 제어의 중요성이 포함된 이 내장 walkthrough에서 나타납니다:
제품 및 엔지니어링은 롤아웃에 대한 시각성을 얻습니다
__CAPGO_KEEP_0__는 오로지 비상 상황에만 사용되는 것이 아니다. 또한 팀이 증거로써 릴리즈 결정을 내릴 수 있도록 도와준다.
Android는 버전 인식의 중요성을 보여주는 좋은 예이다. Android의 공개 버전 히스토리는 2007년 11월 5일에 출시된 베타 버전으로 시작된다. 첫 번째 상업 버전은 Android 1.0 이고 2008년 9월 23일에 출시되었다. 플랫폼은 현재 3억 개 이상의 활성 장치로 성장했다.. 최신 주요 릴리즈는 Android 15 이고 2024년에 출시되었다. Android 14 향상 미국에서 2024년 중반까지 35%의 채택, Android 11 인도에서 가장 퍼진 상태로 남아 28%의 채택. Android도 일반적으로 1년에 한 번의 주요 업데이트를 배포 Android 버전 역사 참조에 따르면.
제품 및 엔지니어링에서 이러한 분산화는 rollout 결정이 가정에 의존할 수 없다는 것을 의미합니다. 앱 버전과 OS 현실, 채널 및 고객 계층에 대한 시각성을 필요로합니다. 그들은 어떤 버전이 어떤 OS 현실, 채널 및 고객 계층에 매핑되는지 알기 때문에 compatibility code을 폐지할 때, rollout을 늦추거나, 더 오래된 경로를 유지할 때 결정합니다.
앱 스토어 역사 vs Live Update History
Store history와 live update history는 서로 다른 문제를 해결합니다. 팀은 하나가 다른 것을 대체할 수 있다고 가정할 때 문제에 처합니다.
The store는 주요 바이너리 릴리스에 대한 공개 기록을 제공합니다. 그게 중요합니다. iOS에서 버전 기록은 원래 iPhone OS에서 2007년 6월 29일부터 시작되었으며 2024년 9월까지 iPhone OS 1에서 iOS 18까지 18개의 주요 버전을 거쳐 왔습니다. 버전 기록은 iOS 2에서 2008년 7월 11일에 도입되었으며 iOS 7에서 2013년 9월 18일에 큰 디자인 전환을 표시했습니다. 플랫폼은 전 세계적으로 1.5억 대의 활성 장치를 제공합니다. 버전 기록은 iOS 2에서 2008년 7월 11일에 도입되었으며 iOS 7에서 2013년 9월 18일에 큰 디자인 전환을 표시했습니다.버전 기록은 iOS 2에서 2008년 7월 11일에 도입되었으며 iOS 7에서 2013년 9월 18일에 큰 디자인 전환을 표시했습니다. 버전 기록은 iOS 2에서 2008년 7월 11일에 도입되었으며 iOS 7에서 2013년 9월 18일에 큰 디자인 전환을 표시했습니다.버전 기록은 iOS 2에서 2008년 7월 11일에 도입되었으며 iOS 7에서 2013년 9월 18일에 큰 디자인 전환을 표시했습니다. 버전 기록은 iOS 2에서 2008년 7월 11일에 도입되었으며 iOS 7에서 2013년 9월 18일에 큰 디자인 전환을 표시했습니다. 버전 기록은 iOS 2에서 2008년 7월 11일에 도입되었으며 iOS 7에서 2013년 9월 18일에 큰 디자인 전환을 표시했습니다. 버전 기록은 iOS 2에서 2008년 7월 11일에 도입되었으며 iOS 7에서 2013년 9월 18일에 큰 디자인 전환을 표시했습니다.버전 기록은 iOS 2에서 2008년 7월 11일에 도입되었으며 iOS 7에서 2013년 9월 18일에 큰 디자인 전환을 표시했습니다. iOS 16 __CAPGO_KEEP_0__ 32%의 미국 활성 iOS 기기 중에서 2025년 초까지이것에 따라 iOS 버전 역사 참조. 그 연간 주기는 원시 릴리스 계획에 유용한 배경입니다.
그러나 운영적으로, 스토어는 여전히粗한 타임라인입니다.
스토어 역사에서 가장 좋은 것은
스토어 릴리스 역사에서는 몇 가지 것에 잘 작동합니다:
| 속성 | 앱 스토어 / 플레이 스토어 | 라이브 업데이트 플랫폼 (예: Capgo) |
|---|---|---|
| 대상 | 공개 및 파트너 대면 | 내부 엔지니어링, 지원 및 운영 |
| 릴리스 단위 | 원본 바이너리 | 번들, 자산, 설정, 대상 패치 |
| 주기 | 제출 및 검토 흐름과 연관 | 배포 PIPELINE의 속도에 따라 |
| 메타데이터 깊이 | 릴리스에 집중된 컨텍스트 | 잘 설계된 경우 세부 운영 메타데이터 |
| 롤백 경로 | 일반적으로 다른 저장소 작업이 필요합니다 | 직접 이전 버전으로 되돌릴 수 있습니다 |
| 수사 | 마일스톤 추적에 좋습니다 | 사고 수준의 조사에 더 좋습니다 |
플랫폼 분배된 바이너리, 승인, 공개 릴리스 노트와 같은 경우 저장소가 올바른 곳입니다. 제품 관리자와 외부 이해관계자는 그 기록을 필요로 합니다. 그것은 가시적이고 안정적이며 플랫폼 정책과 일치합니다.
라이브 업데이트 기록이 게임을 바칩니다
팀이 자바스크립트, 자산, 복사본, 또는 구성 변경을 저장소 검토 경로 외부에서 배포한다면, 내부 버전 기록이 공개 릴리스 노트보다 더 중요합니다. 그곳에서 많은 모바일 PIPELINE이 현재 일상 생활을 합니다.
중요한 제한은 API 깊이입니다. App Store Connect와 같은 공개 API는 버전 기록을 노출할 수 있지만 50개의 역사적 결과 제한을 적용합니다. 이것은 완전한 장기 분석을 막고, 규정 준수 또는 수사 작업을 더 어렵게 만듭니다. 이 점은 이 문서에서 언급되어 있습니다.limit of 50 historical results App Store Connect의 기록 제한그 제한이 하나의 이유로 팀이 내부 버전 추적을 구축하거나 채택하는 것입니다. 내부 버전 추적은 전체 버전 기록을 저장하고 채널 기반 배포를 지원합니다.
공개 API의 얕은 기록에 의존하는 사고 시간표가 있다면, 당신은 사고 시간표가 아니라 부분적인 기억을 가지고 있습니다.
실시간 업데이트 기록은 개인적이면서도 검색 가능한 것이어야 합니다. 또한, 차이점 업데이트, 채널 대상, 배포 원본, 설치 상태, 롤백 관계를 보여주어야 합니다. 또한, 다음의 운영 질문에 대한 답을 얻을 수 있어야 합니다: Beta 사용자에게 먼저 보낸 프로덕션 핫픽스는 무엇인가? 마지막 네이티브 릴리스 이후에 배포된 자산만 업데이트한 것은 무엇인가? 마지막 안정 버전을 지원해야 하는 버전은 무엇인가?
배포 모델을 평가하는 팀에게는 이 distinction은 실용적이지요, 철학적이지 않습니다. 앱 스토어 업데이트와 직접 업데이트 비교 이 비교는 버전 기록 요구 사항을 형성하는 통치와 속도 상의 트레이드 오프를 강조하기 때문에 검토할 가치가 있습니다.
버전 기록 데이터 모델 설계
유용한 앱 버전 기록은 데이터 모델에서 시작됩니다. schema가 얕다면, 기록도 얕게 될 것입니다. 팀은 일반적으로 버전 번호와 빌드 번호를 추적합니다. 채널, 패치, 롤백을 추가한 후에는 충분하지 않습니다.
일단부터 저장할 필드
모델은 일반적인 운영 질문을 쉽게 대답할 수 있어야 합니다. 이 필드는 대부분의 작업을 수행합니다:
- versionId 유니크한 내부 식별자로 사용되며 변경되지 않습니다.
- __CAPGO_KEEP_0__ 인간이 읽을 수 있는 릴리스 레이블.
- __CAPGO_KEEP_0__ 네이티브 플랫폼 시퀀싱을 위해.
- __CAPGO_KEEP_0__ 제품, 스테이지, 베타, 또는 고객 특정 롤아웃 스트림.
- __CAPGO_KEEP_0__ 정확한 배포 시간.
- __CAPGO_KEEP_0__ 릴리스를 시작한 개발자, 서비스 계정 또는 CI PIPELINE.
- __CAPGO_KEEP_0__ 원본 제어에 대한 추적성을 위해.
- releaseNotes 내부 컨텍스트에만 사용하는 것이 아니라, 공개 마케팅 콘텐츠도 아닌.
- 아티팩트 URL 바이너리 또는 패키지 위치를 위한.
- 버전 ID가 빠르게 롤백이 가능한 이유. draft, active, rolled back, retired, 또는 failed 상태를 위한.
- 사무실의 백보드에서 복잡한 데이터베이스 엔터티 관계 다이어그램을 그리는 전문 개발자. 하이브리드 앱의 이름과 릴리즈 식별자에 작업 중이라면, __CAPGO_KEEP_0__ 앱의 버전 태깅에 대한 이 안내서를 참조하세요.
supersedesVersionId 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"
}
}릴리스 기록을 저장하는 것은 모든 지원, 보안 및 엔지니어링 팀이 같은 날에 필요할 때와 마찬가지로, 지원, 보안 및 엔지니어링 팀이 필요할 때와 마찬가지로.
The key is consistency. Every release path should emit the same core metadata, whether it comes from Xcode Cloud, GitHub Actions, Bitrise, Fastlane, or a custom script. If one path skips author identity and another skips channel information, the history becomes harder to trust.
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. 이에 대한 how Capgo handles version control and rollbacks 모바일 팀이 자주 업데이트를 푸시하기 시작한 후에 일반적으로 필요로 하는 운영 모델의 종류를 보여주는 이 개요
대시보드 뷰가 중요합니다. 응답자들은 raw logs에서 릴리스 상태를 재구성하는 시간이 없습니다.
스크린샷
Rollback without guesswork
좋은 롤백 흐름은 '어떤 버전을 시도해야 하나?'라는 질문으로 시작하지 않습니다. 이전에 안정적인 릴리스가 명확한 visible chain of revisions에서 시작합니다.
- 그것은 몇 가지 구체적인 방식으로 incident response의 품질을 바꿉니다. 엔지니어링은 확신을 얻습니다.
- 팀은 정확한 hotfix 후보와 그 전의 버전을 식별할 수 있습니다. 지원은 스크립트를 받습니다.,
- 제품이 포함된 범위: 관련자들은 이슈가 하나의 채널이나 릴리즈 웨이브에만 국한되어 있는지 여부를 볼 수 있습니다.
이것도 사후 분석을 개선합니다. 이슈가 패치로 인해 발생했는지에 대한 팀의 의견 대신, 다음 순서를 지시할 수 있습니다: 네이티브 빌드 승인, 라이브 번들 배포, 오류 보고, 롤백 트리거, 안정 번들 복원. 그 정도의 추적성은 앱 버전 기록을 관리에서 릴리스 제어로 바꾸는 것입니다.
기록 관리에서 릴리스 제어로
앱 버전 기록은 일반적으로 문서로 간주됩니다. 숙련된 팀은 이를 운영 제어 표면으로 다룹니다.
이 변화를 중요시하는 이유는 모바일 배포가 현재 두 개의 시계에 달려 있습니다. 첫 번째는 스토어 시계로 네이티브 바이너리, 공개 릴리스, 검토 기반의 리듬을 다룹니다. 두 번째는 라이브 업데이트 시계로 빠른修정, 목표된 롤아웃, 롤백 속도를 다룹니다. 만약 첫 번째만 추적한다면, 가장 빠르게 움직이는 순간에 눈치채지 못합니다.
강력한 기록 시스템은 지원에 신뢰할 수 있는 답변, 제품에 실제 론칭 그림, 그리고 엔지니어에게 안전한 상태로 돌아가기 위한 안전한 경로를 제공합니다. 또한 릴리스에 대한 일반적인 두려움을 제거합니다: 사용자가 실행 중인 정확한 버전을 모릅니다.
현재 릴리스 PIPELINE을 검토하세요. 다음 질문 하나만 생각하세요. 다음 시간에 프로덕션에 문제가 발생하면, 팀이 나쁜 리비전을 식별하고 역전할 수 있는지 여부를 알 수 있나요? 만약 '아니오'라면, 버전 기록이 개선이 필요합니다.
Capgo가 Capacitor 팀에게 버전 기록을 릴리스 작업의 일부로 다루는 것을 도와줍니다. 릴리스 노트만 다루는 것이 아니라. channel-based 실시간 업데이트, 배포 기록, 롤백 지원이 같은 워크플로우에서 필요하다면看看 Capgo.
