출근했는데, 인수인계서가 없다.
만 4년만에 이직을 했다. 이번에는 내 경력을 쳐주고 내가 자리를 잡을 수 있는 곳으로 가고자하고 이직했다. 다행히 운 좋게 여러 조건들이 충족하는 곳으로 가게되었고 대망의 첫 출근날이 왔다. Git 권한을 받고 프로젝트를 실행했다.
... 처참했다.
그리고 상급자들은 내게 앱 개발 프로세스 정립을 요구했다. 정확하게는 문서에 대한 질문에 ‘없습니다. 정해야합니다.’ 라는 답변만 앵무새처럼 반복됐다.
이건요? 저건요? 이렇게 안했나요?
- 책임님이 지금 이야기하는 게 다 맞는 이야기입니다. 그대로 진행해주십쇼.
출근 2일만에 갑자기 프로세스를 만들어야하는 준관리자가 되었다. 덕분에 이것만 해도 수습은 그냥 행정적인 절차가 되겠다는 생각이 들었다.
출근 한 주만에 이렇게 내가 할 수 있는 걸 다 보여줘도 되는 건가? 하는 생각이 들었다. 이 다음에 더 이상 보여줄게 없으면 어쩌지, 인사평가는 어떻게 되는 거지? 그리고 그냥 생각을 접었다. 이것만 잘 잡아놔도 나는 할일 다 한거다.
프로세스를 만드는 데 있어 가장 먼저 내가 하고싶었던 이상적인 배포 프로세스를 생각해봤다.
기본적으로 브랜치는 main, staging, dev로 상시 운영한다.
스프린트 생성 후 dev에서 해당 스프린트로 브랜치를 생성한다.
JIRA에서 해당 스프린트에 작업이 생성되면 담당자가 작업의 티켓 번호로 브랜치를 생성한다.(자동이면 좋겠다.)
티켓 안에 하위 작업은 커밋의 말머리에 기록한다.
해당 작업(티켓)이 마무리되면 PR을 하고 리뷰어가 리뷰한 뒤, 머지한다. (해당티켓의 상태는 개발완료로 바뀐다.)
그렇게 모든 작업이 마무리되면 스프린트 브랜치로 PR을 한다.
모든 스프린트가 머지되면 dev 브랜치에 머지한다. (리뷰여부는 고민중이다.)
dev에 머지되면 빌드머신이 빌드를 한다.
테스트 빌드가 업로드 되고 모든 티켓의 상태가 QA로 변경된다.
QA에서 리젝나면 다시 수정용 브랜치를 딴다. (네이밍은 고민중이다.)
티켓의 상태가 모두 QA완료로 바뀌면 (몇가지는 보류로 결정될수도 있겠다.) 빌드머신이 배포용 빌드를 한다.
스토어에 올려서 심사를 보낸다.
심사가 통과되면 스프린트를 배포 상태로 변경하고 깃에 버전을 태그로 달고, 커밋 메세지와 티켓 메모를 기반으로 릴리즈 노트를 작성한다.
내가 이걸 쓰고 난 뒤에 내 감상평은 진짜 너무 귀찮겠다 였다. 그래서 무조건 자동화가 필수라고 생각했다. 그래서 자동화 세팅할 수 있는 걸 정리하라고 했다.
[Jira] 카드 브랜치 생성 커밋/PR 리뷰/머지
[GitHub Actions] 빌드 트리거 빌드머신 배포
[빌드머신] Fastlane Firebase/AppCenter QA 배포
[Jira] 상태 업데이트 QA 진행 릴리즈 노트 생성 스토어 업로드 태그 생성
Jira GitHub 이슈 자동 연동 : GitHub for Jira
Slack 알림 연동 : GitHub Actions + Slack Webhook
빌드머신 관리 : macOS + Fastlane + ngrok (Webhook 테스트용)
릴리즈노트 자동화 : conventional-changelog
버전 관리 : standard-version
Jira: API Key / Webhook 등록 / 상태 전환 스키마 정의
GitHub: 브랜치 전략 / CODEOWNERS / PR 템플릿 / Actions 작성
Fastlane: Android + iOS lane 구성 (beta, release)
빌드머신: Webhook Listener 구축 + Fastlane 실행
Slack: 배포 알림 채널 연동
Tag/Release: 자동 태깅 + Release Note 생성 워크플로우
기특한 녀석, 너라도 있어서 다행이다.
안에 테스트 코드 작성이라던지 이런 부분이 생략되어있는데, 테스트 코드를 짜본 적이 없어서 너무 난해하다. 이건 많은 참고가 필요할 것 같고, 일단 이 정도로 밀고 갈지 한번 피드백을 받아보려고 한다. 이상과 현실은 다르니까 회사가 어느정도까지 용인해줄지는 부딛혀봐야 알겠지!