게임 빌드 버전 관리 정책 제안
개요
게임 앱의 안정성, 품질, 일관성을 유지하기 위해 빌드 버전 관리 체계를 수립.
운영 및 업데이트 과정에서 개발, QA, 배포 간의 명확한 커뮤니케이션을 지원.
사용자 경험을 향상시키기 위해 버전별 기능 및 문제 추적을 용이하게 함.
본 버전 정책 제안 가이드는 런칭 전 릴리즈 버전 선점으로 인한 문제를 방지하기 위한 가이드 입니다.
iOS
1) Bundle Version (CFBundleShortVersionString)
마케팅 버전(사용자 표시)
예:
1.2.0,0.0.1000등실제 사용자에게 보이는 버전이며, 일반적으로
Major.Minor.Patch형태를 사용합니다.
2) buildNumber (CFBundleVersion)
빌드 식별자(내부 식별)
예:
42App Store Connect에 업로드할 때, 이전에 업로드한 빌드 번호보다 커야 합니다.
iOS에서는 문자열 형태(
1.0.0)도 가능하지만, Android와 통일성을 유지하기 위해 정수 형태를 사용하는 것을 권장합니다.
예시 규칙
Dev:
0.0.1000QA:
0.100.1Release:
1.0.0
개발 편의를 위해 실제 유저에게 표시되는 버전과 개발용 버전(Dev/QA 버전)을 구분 지어 두면, 어느 빌드가 어디에 쓰였는지 빠르게 파악할 수 있습니다.
Android
1) Bundle Version (versionName)
마케팅 버전(사용자 표시)
예:
1.2.0,0.100.1등실제 사용자에게 보이는 버전이며, 일반적으로
Major.Minor.Patch형태를 사용합니다.
2) Bundle Version Code (versionCode)
빌드 식별자(내부 식별)
예:
42Google Play Console에 업로드할 때, 이전 버전 코드보다 커야 합니다.
정수(Integer)만 사용 가능하며, iOS와 달리 문자열 형태를 지원하지 않습니다.
예시 규칙
Dev:
0.0.1000QA:
0.100.1Release:
1.0.0
마찬가지로 내부 테스트 및 QA 단계에서 versionName을 구분해두면, 빌드가 여러 개 올라가더라도 쉽게 식별할 수 있습니다.
공통 권장 사항
빌드 번호 증가
TestFlight(iOS), Firebase App Distribution(Android) 등 베타 배포 툴을 사용할 경우, 빌드할 때마다 빌드 번호(또는 versionCode)를 +1씩 자동 증가시키는 것이 좋습니다.
로컬에서 임시로 빌드하여 테스트하는 수준이라면 굳이 번호를 올릴 필요는 없습니다 (어차피 스토어/베타 채널에 업로드되지 않으므로)
버전 체계 통일
iOS
CFBundleVersion은 문자열 사용도 가능하지만, Android와 맞추어 정수 형태로 통일하는 편이 프로젝트 관리에 유리합니다.
마케팅 버전 vs. 내부 버전
사용자에게 표시할 버전(예:
1.0.0)과 개발/QA용 버전(예:0.0.1000)을 적절히 구분하여, 빌드마다 “이게 어느 단계(Dev/QA/Release)의 버전인가?”를 명확히 알 수 있도록 하면 추적이 쉬워집니다.
Last updated