안드로이드 버전 코드 올리기 전 결제 회귀 테스트까지 챙기는 릴리즈 루틴

versionCode 7 올리면서 했던 생각들

v1.0.4 릴리즈 준비하면서 build.gradle 만 한 줄 바꿨음. versionName "1.0.4", versionCode 7. 진짜 별거 아닌 커밋인데, 이걸 손볼 때마다 머릿속에 체크리스트가 돌아가서 정리해둠.

versionName vs versionCode

매번 헷갈려하는 동료가 있어서 정리.

defaultConfig {
    versionCode 7
    versionName "1.0.4"
}

versionName 은 마케팅용이라 "1.0.4-hotfix" 같이 막 써도 동작함. 근데 versionCode 는 무조건 단조 증가하는 정수여야 함. 한번 7 올리면 다음엔 8 이상이어야 하고, 7 로 되돌아오면 스토어가 막아버림. 그래서 hotfix 한답시고 옛날 브랜치에서 빌드 올리려다가 versionCode 충돌나는 사고 한번 본 적 있음.

왜 매번 한 줄짜리 커밋을 분리하나

릴리즈 직전에 기능 커밋이랑 버전 bump 를 한 커밋에 묶어서 올리던 시절이 있었는데, 롤백할 때 항상 후회함.

• 이유 1: 버전 bump 만 분리하면 git log --grep="versionCode" 로 릴리즈 히스토리가 깔끔하게 잡힘
• 이유 2: 기능 커밋이 문제될 때 그것만 revert 해도 versionCode 는 그대로 유지 가능
• 이유 3: 릴리즈 노트 자동화 스크립트가 versionCode 커밋을 anchor 로 쓰기 좋음

이번에도 1.0.3 → 1.0.4 한 줄짜리 단독 커밋으로 분리. 별것 아닌 것 같아도 6개월 뒤 내가 고마워할 일.

체크리스트 박제

빌드 올리기 전에 매번 도는 루프:

• [x] versionCode 가 직전 릴리즈보다 큰가
• [x] versionName 이 시맨틱 버저닝 규칙대로 올라갔나 (patch/minor/major)
• [x] 변경사항이 patch 수준 맞나 — 버그 픽스만 들어갔으면 1.0.x, 신규 기능이면 1.x.0
• [x] 릴리즈 노트 초안에 사용자 관점 변경점이 적혀있나
• [x] 결제 플랫폼 연동 쪽 회귀 테스트 한 번 더 (파트너 정산 흐름은 patch 라도 항상 확인)

사소한 한 줄, 무거운 책임

versionCode 한 칸 올리는 게 코드 라인 수로는 1줄인데, 그 뒤에 깔린 의미는 "이 빌드가 나가면 되돌릴 방법이 제한된다"는 거라서 매번 긴장함. 특히 결제 흐름 들어간 빌드는 versionCode 올린 그 순간부터 사용자 단말에 박힐 수 있다고 생각하고 손댐. 한 줄 커밋이라고 가볍게 보면 안 됨.

다음