작업 매뉴얼
-
major.minor.patch
- 정식 개발 프로세스 (일반적인 개발 프로세스)
- Sprint Development Life Cycle
- 일정 산출 > Sprint 에서 진행할 작업들을 추린다 > 개발 진행 > 작업들을 모아서 Release!
- 작업 Sprint 와는 별개로, 별도의 플래닝 없이 자유롭게 작업 & 배포 가능
- 버그 수정
- 기능에 변화가 없거나 변화가 미미한 작업
- 하위 버젼 호환 필수
-
Issues에서 이슈 생성 (작업 티켓) 생성 -
dev에서작업 브랜치딴다
- [2-1] 일반 개발:
feat/[issue number]-optional-explanatory-postfix(e.g. feat/123-sthg-task) - [2-2] 핫픽스:
hotfix/[issue number]-optional-explanatory-postfix(e.g. hotfix/123-urgent-task)
- 작업 완료 후,
작업 브랜치->dev로 PR -
작업 브랜치->devPR 머지 시,Squash and merge로 머지 - 개발 환경에
dev브랜치로 배포하여 기능동작 확인! (BE 배포 방법, FE 배포 방법) -
dev->main으로 PR
- [6-1] sprint (major, minor version up) 개발: 모든 작업물들이
dev에 머지 완료되면 PR 날린다 - [6-2] patch (patch version up) 개발: 작업 진행자가 필요 작업들이
dev에 모두 머지 완료되었다고 판단한다면 PR 날린다
-
dev->mainPR 머지 시,Create a merge commit로 머지 -
Releases에 작업 내역 관련하여 릴리즈 노트 작성 (main브랜치 기준) - 상용 환경에
main브랜치로 배포하여 기능동작 확인! (BE 배포 방법, FE 배포 방법)
- 커밋 내용에 맞게 아래 나열된 커밋 메세지 포맷 중 하나를 골라 사용한다
- feat:
- fix:
- refactor:
- docs:
- style:
- chore:
- test:
e.g.
feat: 로그인 구현
test: XXX 테스트 작성
...
- 제목에 커밋 컨벤션과 같이 prefix를 붙여 기능 구현인지 수정인지 명시
e.g.
feat: login 기능 구현
or
hotfix: login XXX 에러 버그 수정
- 기본적으로 템플릿이 존재하므로, 템플릿에 맞춰 작성하면 된다
- Close된 PR들 둘러보고 참고해봐도 좋을 것 같다
- FE Semantic Versioning 이 버젼 (major, minor, path 모두) 이 올라가는 상황마다 항상 적용 되어줘야 한다 (링크 참고)