[CI/CD] Github Action을 이용한 자동화와 브랜치 전략

0. 왜 자동화를 시작하게 되었나

이전 프로젝트에서는 PR 하나마다 스크린샷과 영상을 첨부했으나, GUI와 기능만을, 그것도 수동으로 확인할 수 있었다. 각자의 개발환경이 다르다 보니 빌드 에러를 제대로 확인하지 않고 PR이 병합되는 상황이 발생했다,,

➡️ CI와 CI 자동화의 필요성

 

사실 vercel에서는 commit과 PR을 기준으로 한 CD 자동화를 코드 없이도 제공한다. 하지만 문제는 난 거지이고... 팀 플랜을 이용하기엔 돈이 아깝다는 것이다. (즉 organization으로 판 레포를 직접 배포할 수 없었다.) 그래서 다들 많이 사용하는 방법인, 팀 레포를 개인 레포로 fork해온 다음 개인레포를 배포하는 방법을 선택했는데, 이게 차아아암 귀찮다. 왜냐하면 포크한 내 레포는 당연하게도 항상 최신상태가 아니기 때문이다.

➡️ CD 자동화의 필요성

 

그래서 선택한 방법은,

1. 누군가 feature 브랜치로부터 develop으로 PR을 날렸다.
2. 이를(PR) 트리거로 설정하여, PR을 날리면 빌드를 한번 해서 에러가 없는지 체크하고 에러가 나면 develop에 merge할 수 없도록 막는다. (CI)
3. 2번에서 통과되면 merge가 가능하다. 누군가 merge를 시도한다.
4. 또다시 이를(merge, commit) 트리거로 설정하여, merge된 결과를 빌드한 후 괜찮으면 배포한다. 안괜찮으면 안한다. (CD)

1. 브랜치 전략

• feature/#이슈번호 (CI 자동화)
• develop (feature에서 개발한 기능, CD 자동화 ~에서~ 수동 싱크로 올리는 것으로 변경했다)
• staging (배포 확정인 기능들 / release QA 시 발견된 이슈 수정사항 반영)
• release (실제 RN에 들어가는 웹뷰 링크, 포크해온 레포에서 수동 싱크로 올리기 ~에서~ CD 자동화 주는 것으로 변경했다)

 

2. 고쳐나갈 점

• 열받는 점은 항상 develop - feature 브랜치로만 개발해오고 배포는 대충 master 게시해놓고 끝냈던 나머지, 실 서비스를 운영해보는 입장에서 staging, release 브랜치의 필요성을 뒤늦게 깨닫고 우당탕탕 분기했다는 점이다.
• 그래서 CD를 develop에 줬던 걸 release로 바꿔놓은 상태라 현재는 수동으로 develop을 배포해야 한다 ㅠ ㅠ
• 기능이 어느정도 정리가 되면 이렇게 꼬인 브랜치 전략을 다듬어야겠다!

 

TODO

• hotfix 브랜치를 잘 활용해보자!
• PR 템플릿, 이슈 템플릿 제대로 만들기 (어떻게 하면 다들 지키게 만들 수 있을까? 템플릿대로 안올리면 아예 못올리게 할 수 있나?)
• 브랜치 템플릿 안지키면 아예 merge 못하게 만들기
• develop, staging, release 세 브랜치에 병합되었을 경우 디코에 알림 연결하기 (스테이징에서 QA 진행해야 하므로 여기도 도메인 따로 파주기)

 

생각해 봐야할 점들

• RN에 대한 CI/CD ... 네이티브쪽에 기능이 추가되었을 때 너무 야매로 올리는 것 같다. 앱 배포는 웹보다 훨씬 많은 과정을 거쳐야 하다 보니 귀찮아서 그냥 수동으로 올렸는데, 웹과 마찬가지로 브랜치 전략이 필요해 보인다.
• abb나 ipa 파일 맨날 만들어내는게 너무 귀찮고, 이걸 만들기 전까지 빌드 에러가 나는지 아닌지 알 수 없다.
• feature별 단위테스트 도입 (API, 함수) ➡️ CI 추가해서 테스트 에러나면 merge 막기
• 스토리북을 통한 GUI테스트 도입 ➡️ CI 추가해서 테스트 에러나면 merge 막기