- 모든것을 기록하기, 귀찮은것들을 자동화 하기
- 코드 Commit/PR 잘 분리하기, PR잘쓰기, 페어프로그래밍 등
이 포스팅은 아래 시리즈로 연재중입니다.
- 헤이딜러 안드로이드팀은 어떻게 일하나요?(1) — 팀문화
- 헤이딜러 안드로이드팀은 어떻게 일하나요?(2) — 업무방식
- 헤이딜러 안드로이드팀은 어떻게 일하나요?(3) — 프로젝트 구조
아직 1편을 읽지 않으셨다면, 이 연재 시리즈의 1편부터 시작해서 읽고 오시길 추천 드립니다.
이번 포스팅에서는 안드로이드팀 업무방식에 대해 소개합니다.🙋🏻♀️ 🙋🏻 🙋🏻♂️
모든것을 기록하라 ✍️
업무를 하면서 정말 많은 대화들이 오고 가게 됩니다.
이런 대화들을 그냥 구두로만 이야기하고 끝내버린다면,
- 나중에 이력을 알기가 어렵고
- 다른 사람이 같은 내용을 다시 또 물어보게 될 수도 있고
- 심지어 나조차 시간이 지나고나면 무슨 이야기를 했었는지 까먹게 됩니다.
그래서 구두로 이야기한것들도 슬랙에 기록해둡니다. ✍️✍️
구두로 논의한뒤, 내가 기록으로 남겨두거나 해당 담당자에게 기록으로 남겨달라고 요청합니다.
혹은, 기획 문서에 구두로 논의된 내용을 반영해서 최신화하기도 합니다.
또한 DM보다는 공개된 채널에서 이야기로 기록을 남기도록 노력합니다.
업무를 진행하면서, 혹은 팀원들끼리 규칙을 정하면서 등 다양한 이유로 오갔던 여러 대화내용들을 Notion의 팀문서에 기록하고 있습니다. 📝
코드 Commit/PR 잘 분리하기
git에 코드를 commit하고 PR을 만드는 방법에서도 정말 다양하고 효율적인 방법이 있습니다.
이 내용과 관련해서는 이전에 작성했던 블로그 포스팅을 읽어보시면 많은 도움이 되실겁니다.
1. 코딩 규칙 정하기
2. Branch와 커밋이름에 이슈번호 prefix로 적기
3. PR과 커밋은 최대한 작은 단위로 쪼개기
4. GitHub 템플릿으로 PR내용 규격화
5. 라벨 활용하기
6. 리뷰어가 빌드 성공여부/코딩컨벤션 확인하지 않기
7. 코드리뷰 내용 반영할때마다 커밋 id남기기- PR과 커밋은 최대한 작은 단위로 쪼개기
- 큰 규모의 피쳐 작업은 작은 단위의 issue/PR로 만들어서 작업하기
PR 잘 쓰기
잘 쓴 글이 읽기 쉽듯이, 잘 만든 PR도 리뷰어가 리뷰하기 쉽습니다.
PR을 만들때 GitHub 템플릿을 이용해서 PR내용을 규격화 합니다.
PR을 만들때 이 템플릿이 자동으로 반영되서 작성됩니다.
물론 아무리 템플릿을 만들어놓았다고 해도, 작성하는 사람이 얼마나 잘 쓰느냐가 중요합니다.
- 어떤 화면을 만들어야 하는지
- 어떤 작업들을 했는지
- 경우의 수 case별 어떤 화면들이 보여져야 하는지
- 테스트는 어떻게 하는지
등의 내용들을 리뷰어가 잘 알 수 있도록 적는것이 중요합니다. 👩🏻💻 🧑🏻💻
귀찮은건 못참지 🙅🏻
업무를 하면서 수동으로 하는 작업이 있거나 귀찮은 작업들이 있다면 최대한 자동화하거나 효율적으로 개선하려고 노력하고 있습니다.
- 수동으로 Jira Version을 만들고, 앱 배포후 Jira에서 버전 Release처리하던 작업을 GitHub Action으로 자동화
- GitHub에서 Release branch를 master로 merge하고나서 Release tag를 수동으로 만들어주던 작업을 GitHub Action으로 자동화
- GitHub에서 Release branch를 master로 merge하면 자동으로 해당 버전의 파일을 GooglePlay에 배포하고 알림
- PR의 상태에 따라서 알아서 Label이 변경되도록 자동화
QA 효율화
QA팀에서 앱을 잘 테스트하고 확인하실 수 있도록 여러가지 방식으로 노력하고 있습니다.
안드로이드팀에서는 QA팀에 APK파일을 전달할때
슬랙이나 메일등으로 직접 APK파일을 전송하지 않습니다.
자체 앱 deploy 서버를 운영해서
- 피쳐별로 APK파일을 확인할 수도 있고
- 앱 버전별로 APK파일을 확인할 수도 있습니다.
QA팀에서는 테스트하길 원하는 피쳐나 앱버전에 해당하는 APK를 찾아서 설치하기만 하면 됩니다.
또한, QA팀에서 테스트하는데 용이하도록 [개발자 모드]를 만들어서 운영하고 있습니다.
[개발자 모드]와 관련된 자세한 내용은 이전에 작성했던 아래 포스팅을 참고해보시면 도움이 됩니다.
- 앱 안에 [개발자 모드]를 만들어서 앱안의 여러 정보를 바로 확인가능
(사용자 정보, 기기 정보 등)
- 테스트 서버 주소 변경, 유저 ID 변경, A/B테스트 값 변경 등
- 현재 테스트중인 앱이 어느 피쳐가 적용된 앱인지, 담당자가 누군인지 등
배포 방식
헤이딜러 안드로이드팀은 릴리즈 트레인을 도입해서 운영하고 있습니다.
안드로이드팀은 매주 금요일을 배포데이로 정하고 배포를 진행합니다. 🚂
- 목요일 오후: 코드 프리징
- 금요일 오전: 릴리즈 테스트 진행
- 금요일 오후: 앱 배포(50% 점진적 배포)
- 월요일 오후: 앱 전체 배포* 물론, 일정이 정해져 있는 피쳐이거나 긴급하게 배포해야 하는 예외 case일때는
배포데이가 아니라도 배포를 진행합니다.
배포단계에서 대부분이 자동화되어 있지만,
결국 배포를 주도적으로 진행해야 하는 사람이 한명은 필요합니다.
안드로이드팀에서는 매주 돌아가면서 배포 진행을 맡습니다.
(당번 제도)
매주 금요일 오전이 되면 자동으로 이번주 어떤 앱들을 배포해야하는지 결정해야 하는 알림이 옵니다.
또한, 실제 배포를 할때 배포 담당자가 배포 슬랙 채널에 배포관련 내용들을 모두에게 알리는 역할을 합니다.
페어 프로그래밍 👩🏻💻 🧑🏻💻
팀원들끼리 페어 프로그래밍을 하는 경우도 있습니다.
- 큰 피쳐 설계를 함께 하는 경우
- 코드리뷰중 주요 내용들을 논의하기 위해서
- 기타 여러 이유로 함께 코드를 만들 필요가 있을때
페어 프로그래밍의 장점과 방식에 대한 내용은 많은 자료들이 있기 때문에
함께 찾아보시면 도움이 되실겁니다.
팀원이 리모트 근무중이거나 간단하게 페어 프로그래밍을 할때는 CodeWithMe도 활용합니다.
아직 Android Studio에 공식적으로 플러그인이 제공되어 있지 않아서
직접 설치해야 하는 번거로움이 있으나, 페어프로그래밍을 하는데 유용한 툴임에는 분명합니다.
지금까지 헤이딜러 안드로이드팀의 업무방식에 대해 소개해드렸습니다.
이 글을 읽으시고 현재 속하신 회사의 좋은 업무방식에 대해서도 공유해주시고 싶으시다면 댓글로 남겨주세요.
또한 다음편인 [3편 — 프로젝트 구조] 편도 많은 기대 부탁드려요
저희와 함께 헤이딜러 서비스를 발전 시켜나가실 분들을 기다리고 있습니다.
감사합니다.
