저의 CI/CD에 대해서는 슬픈 전설이 있어요
노션에 이 내용에 대해 다 정리해서 올려 놓은 경험이 있는데 팀원은 하나도 이해하지 못 했었답니다... 후후
제가 주로 사용하는 CI/CD
CI(Continuous Integration): 지속적인 통합
CI는 앞에서 말했던 Husky, ESLint, Prettier을 사용하여 관리 하였습니다
이를 통해 코드의 일관성과 빠른 리뷰가 가능했습니다
CD(Continuous Deployment): 지속적인 배포
CD는 Vercel을 사용하였습니다 (Netflify도 있음)
팀 프로젝트는 배포가 유료였기에 개인 레포지토리에 포크 후 수동으로 sync를 맞추었다는 후문이...
GitHub
GitHub 커밋 메시지 규칙
Github의 커밋 메시지 규칙은 다음을 따랐습니다
type: title (제목) //필수 작성
body(본문) //필수 아님type은 [feat, fix, refactor, chore, style...] 등이 있는데 보통 feat, fix를 주로 사용했습니다
보통 커밋할 코드 내용에 따라 type이 결정됩니다
title에는 핵심 내용이 들어가 있습니다
body에는 꼭 필요한 내용이 있을 때 작성합니다
보통 코드 변경의 이유 등이 들어갔습니다
Branch 전략
Branch 전략에는 크게 2개가 있습니다
Git Flow와 GitHub Flow인데 저는 보통 Git Flow를 사용했습니다
깃 브랜치 전략은 깃 브랜치 전략 정리에 정말 친절하게 나와있습니다
새로운 브랜치를 만들 때는 항상 어떤 브랜치 인지 알 수 있도록 feature/login, fix/axios 등으로 브랜치 이름을 만들어야 합니다
develop 혹은 master 브랜치는 직접 push를 하면 대참사가 날 수 있기 때문에 꼭 setting 에서 rules를 설정하시는 것을 추천 드립니다
저는 PR을 할때도 대참사가 날까봐 Rebase를 하지 않았다면 Merge자체를 하지 못하게 했답니다
여유있게 프로젝트를 진행했기에 가능했던 일 같아요 ㅎ,ㅎ
Issue와 PR(Pull Request)
issue와 PR은 템플릿을 사용해줬습니다
.github 폴더에 마크 다운 형식으로 각각 ISSUE_TEMPLATE(폴더 안 여러 템플릿), pull_request_template 파일을 저장해주면 템플릿이 저장이 됩니다
issue는 팀원이 무엇을 하고 있고 코드를 어떻게 짯는지 알 수 있기 때문에 정말 중요한! 역할을 합니다
그런데 다들 까먹고 PR적고 issue를 적는 경우가 많더라구요
밑에는 이슈 템플릿 예시입니다
PR은 develop에 직접적으로 push를 하는 대신 다른 브랜치에서 커밋을 한 후 모아서 merge를 할 수 있도록 하게 합니다
issue로 먼저 todo를 짜고 완료(부분 완료)한 다음 PR에 issue를 담고 리뷰를 받은 뒤 Merge를 시켜줍니다
PR에서 closed #이슈번호 를 하면 자동으로 이슈가 닫힙니다
투두를 완료한 issue는 PR에서 닫아주는게 좋겠죠?
참고로 앗! 내가 코드를 수정했는데 PR을 다시 날려야하나?
걱정 하실 필요 없습니다 ㅎ.ㅎ
PR에서 최신 브랜치로 반영해줍니다
이쯤에서 이야기를 마치도록 하겠습니다
어느덧 새벽 5시 20분 ㄷㄷ
다음에는 실제 개발을 했을 때를 회고 해야겠어요
0개의 댓글
