🌱 초기 Github
시스템이 갖춰지지 않은 대부분 초기 스타트업은
github을 러프하게 사용하는 경우가 대다수 입니다.
혼자 일할 때는 큰 불편함은 없지만
협업을 하면 불편하거나 효율적이지 않은 부분이 보이고
이를 위한 시스템을 구축하기 시작합니다.
👀 이직한 회사에서 처음 눈에 띈 부분은
PR 부분이였습니다.
PR에서 다음과 같은 항목이 직관적으로 보이지 않았습니다.
- feature 성격의 개발을 진행한 PR인지 유지보수 성격으로 개발한 PR인지
- 무엇이 변경 되었는지
📝 PR 작성 > 템플릿화
개발자가 PR을 요청할 때 매번 복사&붙여넣기가 아니라
PR 요청 시 > Add a description에
자동으로 템플릿이 삽입되어 있는 구조로 설정 했습니다.
- .github 디렉토리 안에 .md(markdown) 넣기
📌 다음과 같은 기준으로 만들었습니다.
- PR의 목적성
- 리뷰를 위한 프로젝트 컨텍스트 확인 링크(jira, figma)
- 무엇이 변경 됐는지 (어떤 개발을 했는지)
- 직관적인 확인 (스크린샷)
- 테스트 항목 확인 및 리뷰어가 추가 테스트 여부를 판단하기 위한
테스트 체크리스트
PR을 위와 같은 기준으로 만들었고
안드로이드에 적용해서 사용하고 있었는데
ios팀원분들도 괜찮다고 생각하셔서
제가 만든 템플릿을 사용하시는
좋은 방향으로 전파됐습니다.
 |  |
|---|
이제 PR을 정돈된 형태로 올릴 수 있게 됐는데
여기서 끝이 아니라 시작입니다.
PR 템플릿을 만들고 이후의 생각의 흐름을 풀어보면
--} PR을 요청받은 Reviewer에게 부담스럽지 않게 올려야 리뷰가 원활하다
--} 그러면 PR을 최대한 잘게 쪼개야 한다
--} 프로젝트 성격에 따라 PR이 많아질 수 있다
--} PR 리스트가 많아지니 PR들이 각각 어떤 상태인지 알 수 없다.
--} PR 리스트를 봤을 때 filtering을 하여 작업한 내용 효율적으로 찾을 수 없다.
Ok~
Labeling 필요성이 생겼으니 만들어야겠다.
🏷️ PR 카테고리화 > Label
그럼 라벨을 어떤 기준으로 생각하고 만들었나요?
라벨은 상태를 나타내기 위해서 만드는데
어떤 범주의 상태들을 만들지 첫 번째로 고민 했습니다.
1. PR
2. Reviewer & Author가 봐야하는 PR List 화면
3. Issue
먼저 PR을 살펴보면
PR은 최대한 작은 단위로 나눠서 올리다보니
해당 PR의 성격이 명확하게 나옵니다.
PR을 올리는 성격은 크게 다음과 같았습니다.
- feature PR
- Issue Fix PR
- Refacotring PR
- App Event PR
- Localization PR
Reviewer 와 Author 가 PR List 화면에서 봐야 할 상태를 생각해보면
- 모니터링 해야하는 상태인지
- 리뷰가 진행되고 있는지
- 머지진행하면 안되는 PR
- 개인사정 혹은 프로젝트 사정에 의해 QuickMerged PR
이슈는 어떤 종류의 이슈인지
- 처리요청
- ui issue
- crash or logic issue
위의 상태들을 바탕으로 만든 Label 입니다.
이제 PR 리스트에서
각 PR들의 상태를 한 눈에 파악하고
각 PR 처리에 대한 효율적인 프로세스를 갖췄습니다.
📢 PR 알림 > Slack
PR을 효율적으로 잘 작성했으면
PR을 잘 노티하는 것도 필요합니다.
리뷰어에게 따로 매번 노티를 드리는 것도
눈치 보일 수 있고 또한 반복 노동의 리소스 낭비입니다.
이 때 슬랙을 깃헙을 연동하면 자동화된 노티가 가능합니다.
💁🏻 설정방법 link
Slack 채널 설정화면
- PR의 코멘트도 보이도록 추가 설정한 부분
위의 과정을 모두 진행하면
Slack에서 연동된 계정으로 멘션이 되고
PR에 대해 자세히 볼 수 있습니다.
📲 PR 모음 > 릴리즈 노트
해당 프로젝트에 대한 개발과 QA까지 모두 끝나면
앱 개발자는 해당 버전에 개발된 것들을 각 환경에 맞게 명시합니다.
- 깃헙에서는 tag를 이용하여 해당 버전에 어떤 업데이트가 됐는지 명시
- 그 외 기록&공지 용도로 회사에서 사용하고 있는 문서 툴(confluence, notion, etc)에 명시
위와 같은 프로세스를 진행하면서 조금 ✌🏻불편했던 부분들이✌🏻 있었습니다.
- 💭 깃헙에서 태그를 남기더라도 특정 기능을 찾기가 쉽지 않다.
- 💭 github에도 남기고 다른 문서에도 비슷한 내용을 다르게 남기는게 개발 내용이 많으면 정리하는데 시간이 꽤 많이든다.
이러한 불편사항에 대해서 개선을 위해 이미 위에서부터 빌드업을 시작했습니다. ✍🏻
- 🌈 최대한 작게 나눈 PR은 모두 기능 및 앱 업데이트 내용이 됩니다.
- 🌈 Labeling 작업을 통해 카테고리화가 되었기 때문에 스코프가 명확합니다.
그러면 이제 잘 정리된 PR을 라벨링된 스코프하에 릴리즈노트로 옮기면 됩니다.
💁🏻 어떻게? > release-drafter
release-drafter 는 위의 요구사항을
모두 만족시켜주는 깃헙액션 입니다.
위의 만들어둔 label과 링크를 참조하여 파일을 만들면
- release-drafter.yml
- config
⭐️ 릴리즈노트가 작업자와 개발 내용이 한 눈에 들어옵니다.
👏🏻 마치며
이직하며 처음부터 눈에띄어 불편하거나 효율적으로 고친 부분이
팀이 일하기 편한 방향으로 긍정적 영향을 발휘했습니다.
이에 저처럼 협업에 고민하시는 분들을 위해 참고가 되실 수 있어
공유하는 마음으로 당시의 고민과 생각의 흐름으로 작성 했습니다.
아직 발전시켜야 할 부분이 많지만
위와 같은 작업을 하면서
불편하고 귀찮은걸 개선시키는 작업 또한
성장의 발판이라고 생각하며
글을 마치겠습니다.
