[Android] 앱을 배포해 봅시다.

열심히 Develop 에서 코드를 짜고 QA까지 통과했다면 릴리즈를 위해서 AAB 를 추출해야겠죠?

앞으로 CI/CD로 자동화까지 고려하고 있지만, 기본적인 워크 플로우를 알고있어야 자동화에 문제가 생겨도 핸들링이 가능할테니 차근차근 따라옵시다.

1. release/version branch

1.1 브랜치 만들기

먼저 릴리즈를 위한 커밋을 하기 위해서 develop에서 release/버전명 (예: release/1.0.0) 브랜치를 생성해줍시다.

이렇게 만들었다면 브랜치를 이동해주세요!

1.2 Baseline Profile 생성하기

최신 코드에 맞춰서 Baseline Profile도 업데이트 해줘야 앱 성능에 도움이 됩니다.

먼저 빌드 변형(Build Variant)을 release로 변경해줍니다.

 

그 후에 Android Studio의 Run Configuration에서 Generate Baseline Profile for app을 실행시켜주세요.

주의 - 꼭 빌드 변형을 release로 변경해주세요! 플러그인이 내부적으로 빌드 변형을 생성해서 난독화 코드에 맞춰 프로파일링을 진행합니다.

 

 

실행이 완료 됐다면 커밋을 해주세요.

 

 

1.3 버전 코드 올리기

이제 새 버전을 출시할 예정이니, 기존 버전보다 높은 버전을 사용해야 해요. gradle/libs.versions.toml 파일을 열어 버전을 수정합니다.

versionCode vs versionName

• versionName: 사용자에게 보여지는 버전 이름입니다. (예: "1.0.0", "2.3.5"). 마케팅 및 버전 식별용입니다.
• versionCode: Google Play Store가 기기를 관리할 때 사용하는 내부 버전 번호입니다. 반드시 정수여야 하며, 스토어에 새 버전을 올릴 때마다 이전 값보다 커야 합니다.

# Before
# App version
versionCode = "1000001"
versionName = "1.0.0"

# After
# App version
versionCode = "1000002"
versionName = "1.0.0"

시맨틱 버저닝 (Semantic Versioning)

우리 프로젝트는 Major.Minor.Patch 방식의 시맨틱 버저닝을 따르고 있어요.

• Major: 기존 버전과 호환되지 않는 큰 변화가 있을 때 올립니다. (예: 1.x.x -> 2.0.0)
• Minor: 하위 버전과 호환되는 새로운 기능이 추가되었을 때 올립니다. (예: 1.0.x -> 1.1.0)
• Patch: 하위 버전과 호환되는 간단한 버그 수정 등이 있을 때 올립니다. (예: 1.0.0 -> 1.0.1)

상황에 맞게 버전을 올렸다면 커밋을 해줍시다.

 

1.4 라이선스 적용하기

아까의 Run Configuration에서 Spotless를 실행해 라이선스를 추가하고 커밋해주세요!

 

2. AAB 추출하기.

./gradlew bundleRelease 명령어를 사용하거나, Android Studio 메뉴의 Build → Generate Signed Bundle / APK...를 사용하여 AAB 파일을 생성해주세요.

추출이 완료되었다면 Play Store에 AAB를 제출하고 심사를 요청하면 출시 준비는 끝!

3. 브랜치 정리해야지?

출시 후 가장 중요한 과정이에요. release 브랜치에 쌓인 변경사항(버전업 등)을 main과 develop 브랜치에 반영하고, release 브랜치를 정리 하면 됩니다.

main은 실제 출시된 코드를, develop은 다음 개발의 기반이 되는 코드를 담고 있어야 하기 때문이겠죠?

3.1 main 브랜치에 릴리즈 병합

main 브랜치는 출시의 공식적인 기록을 남기는 곳이에요. release 브랜치의 내용을 하나의 '머지 커밋'으로 남겨, "v1.0.0 출시가 이뤄졌다"는 히스토리를 남길거에요.

# 1. main 브랜치로 이동
git checkout main

# 2. --no-ff 옵션으로 머지 커밋을 생성하며 병합
git merge --no-ff release/1.0.0

--no-ff (No Fast-forward) 옵션이란? main 브랜치에서 release 브랜치가 분기된 이후 main에 다른 변경사항이 없었다면, 기본 merge는 main의 포인터를 release의 마지막 커밋으로 그냥 이동시킵니다. 이렇게 되면 release 브랜치에서 작업한 모든 과정이 하나의 흐름처럼 보여, 릴리즈 작업이었다는 맥락이 사라집니다. --no-ff 옵션은 "릴리즈 브랜치를 병합했다"는 사실을 담은 머지 커밋을 생성해 히스토리를 명확하게 관리해줍니다. GitHub에서 PR을 머지할 때 기본적으로 이 방식으로 동작합니다.

3.2 릴리즈 태그 생성

방금 main에 생성된 머지 커밋에 v1.0.0과 같은 태그를 붙여, 해당 릴리즈 시점을 영구적으로 기록합니다.

# -a 옵션으로 주석을 포함한 태그를 생성합니다.
git tag -a v1.0.0 -m "Release version 1.0.0"

3.3 main 브랜치와 태그 원격 저장소에 푸시

로컬에서 완료한 main 브랜치의 병합 결과와 태그를 원격 저장소(GitHub)에 업로드합니다.

# --tags 옵션으로 로컬에 생성된 모든 태그를 함께 푸시합니다.
git push origin main --tags

3.4 develop 브랜치에 릴리즈 변경사항 동기화

release 브랜치에서 올렸던 버전 정보 등을 develop 브랜치에도 동일하게 반영하여, 다음 개발이 최신 릴리즈 상태에서 시작될 수 있도록 해주세요.

# 1. develop 브랜치로 이동
git checkout develop

# 2. release 브랜치 병합 (여기서는 --no-ff 옵션이 필수는 아님)
git merge release/1.0.0

# 3. 원격 저장소에 푸시
git push origin develop

3.5 release 브랜치 삭제

release 브랜치는 로컬과 원격 양쪽에서 삭제하여 저장소를 깔끔하게 관리합니다.

# 1. 로컬 브랜치 삭제
git branch -d release/1.0.0

# 2. 원격 브랜치 삭제
git push origin --delete release/1.0.0

 

이제 모든 릴리즈 후 정리 작업이 완료되었습니다 :) 앱 출시까지의 스프린트 함께 해준 팀원들에게 감사드립니다ㅎㅎ

프로젝트도 많은 관심 부탁드려요!!!

GitHub - Hi-lingual/Hilingual-Android: 하이링구얼 안드로이드 레포지토리입니다.