브랜치 전략과 배포 방법
- main: 운영 서버 배포 브랜치
- 항상 배포할 수 있는 안정된 상태의 코드가 머지되어 있어야 한다.
- 배포를 완료한 후에는 배포한 개발자가 main -> develop 브랜치로 머지한다. 각 feature 브랜치의 담당 개발자가 main → feature 브랜치로 머지하는 것도 권장한다.
- 깃헙의 PR을 이용해서 머지한다.
- develop: 개발 서버 배포 브랜치
- 절대 develop → main 으로 머지하지 않는다.
- 주기적으로 main 브랜치에서 새로운 develop 브랜치를 만든다.
- 깃헙의 PR을 이용해서 머지한다.
- 작업 브랜치: main 브랜치에서 생성한다. 작업의 종류에 따라 아래 네이밍 컨벤션을 따른다.
- 작업 브랜치 네이밍 컨벤션
- feature: feature/{issueNumber}-{description}
- refactoring: refactor/{issueNumber}-{description} (refactoring 의 description 은 필요한 경우 작성)
- bug: bug/{issueNumber}-{description}
- 개발이 완료되면 PR을 생성해서 build 성공 여부를 확인 후, develop 브랜치에 머지해서 개발 환경에 배포한다.
- 운영 환경에 배포할 준비가 되면, 깃헙의 PR을 이용하여 main 브랜치에 머지한다.
- 작업 브랜치 네이밍 컨벤션
- hotfix : 운영 배포 이후 장애 발생 시 이를 대응하는 브랜치
- hotfix 브랜치는 main 에서 만든다.
- 배포할 작업 브랜치를 main 브랜치에 깃헙 PR을 이용해서 머지한다.
-
release 관리 페이지 에서 tag 를 생성한다. 버전은 아래 규칙을 따른다.
- patch version: bug fix, refactoring
- minor version: 기능 추가 등의 작업
- major version: F/W 버전 변경, 인프라 변경 등의 작업
- 아래 내용을 참고하여 배포를 진행한다.
프론트엔드와 백엔드 배포 방법은 동일합니다 :)
