스프린트#4 (05.12 ~ 05.25) 요약
Agenda: Bug Festival
스프린트 변경사항
스프린트 특이사항
Beta branch 관리
Google Play Console 을 이용하여 베타 트랙과 프로덕션 트랙을 구분하여 관리하기로 하였다.
기존 master, staging, develop 으로 구분되던 branch 를 beta/master, beta/staging 2개의 branch 를 추가했다.
베타버전은 beta/master 에 관리하고 베타버전의 이슈 사항들은 beta/staging에서 관리하는 형태로 branch 규칙을 추가하였다.
branch 구성 고민의 흔적
릴리즈 정책 문제발생
알라미 Android는 Production 과 Beta 를 구분하여 기능을 제공하고 버전을 관리하고 있다.
Beta 등록한 사용자들은 Production 보다 빠르게 신규 기능을 체험할 수 있지만 신규 기능을 테스트하게되니 Crash 발생 확률이 있다.
기존에는 Beta 는 100% 내보내고 Production 을 단계적 배포를 진행해왔으나 실험적으로 Beta 도 단계적 배포를 진행하고 Beta / Production의 용도를 좀 더 구분하기로 하였다.
그러다가 Zendesk를 통해 들어온 유저 피드백이 Beta 사용자인데 갑자기 Beta 가 아니게 되었다라는 피드백을 받았다. 처음에는 유저가 Beta track에서 빠져나오고 착각한 것으로 생각했으나 상황 파악을 하다보니 그것이 아님을 알게되었다.
공개 베타 트랙과 프로덕션 트랙이 독립적으로 진행 될 것으로 기대했으나,
프로덕션에서 베타보다 더 높은 version code를 갖게되면 베타 트랙에 등록한 유저도 프로덕션에 있는 트랙을 업데이트하게 된다.
쉽게 말해 베타 테스트 참여자들은 베타 트랙, 프로덕션 트랙 상관없이 그냥 Version Code가 높은 앱을 설치하게 된다.
베타는 프로적션보다 버전이 항상 높아야 기대하는 형태로 관리할 수 있게 된다.
스프린트#2-4 회고
Good
- 안드로이드 이력서를 확인하면서 채용의 기대감이 올랐다.
- 기술적인 것을 적용해서 좋았다.
- 리디자인 진행
- Beta/Prod 관리를 위한 gitflow의 문제점을 발견하여 개선했다.
To improve
- 버전과 트랙 관련 내용 완벽하게 숙지하지 못한 상태에서 출시
- 디버그 버전이 올라와도 General QA 시나리오와 겹치면, 중복을 피하기 위해 QA일정이 밀려 디버그 활용 어려움
- 개발 완료된 항목에 대해 좀 더 잘 노티를 받을 수 있는 방법이 있으면 좋을 듯.
- 특정 이슈 story point 선정 실패
- OKR 중간 점검하면서 신경 쓰지 못한 것들을 알게 됐다.
- Kotlin 전환 전까지 포인트 산정을 신중하게 해야할 것 같다.
- 불명확한 과거 코드가 많아 어려움이 있다.
- 휴가 때 배포 관련 진행을 하였다.
