[Deploy] 배포 브랜치 git 전략 재수립🚀🚀

[kwonsye]

• 기존 배포 전략

  • develop 브랜치에서 배포준비가 완료된 release/{버전} 브랜치를 치고 해당 release 브랜치를 배포한다.

• 기존 배포 전략의 문제

  • 빈번한 minor 및 major 버전업이 번거로운 문제
  • 버전 별 release 브랜치가 여러 개 생기는 문제
  • 버전 별 release 브랜치가 변경될 때마다 서버의 배포 스크립트의 브랜치명을 수정해주어야하는 문제

• 버전에 대한 정보는 tag 를 붙이는 방식으로 배포 전략을 재수립하자.

완료 조건

• [x] 새로운 배포 전략을 해당 이슈 하단 댓글에 문서화한다.
• [x] 기존 배포 전략에서 release 브랜치들을 정리하고 새로운 배포전략 변경사항을 적용한다.

Related issue

• 없습니다.

Reference

• Git Branch & Tag를 활용한 프로젝트 배포 전략 마련하기

Check List

• [ ] 관련 issue가 있다면 추가했나요?
• [x] 유의미한 label을 추가했나요?

---

[kwonsye]

Git flow

[kwonsye]

새로운 배포 브랜치 전략

• 기본적으로 배포하는 브랜치 : master
• master 을 배포하기 전 스냅샷에 배포 버전을 명시하는 tag 를 v{major version}.{minor version}.{patch version} 형식으로 붙인다. ex) v1.9.0
• remote repository 에 존재하는 브랜치는 오직 master 와 develop 브랜치이다.
• 이외의 feature , bug-fix , release 브랜치는 모두 local repository 에서 진행된다.

배포 프로세스

1. 기능 개발은 local의 feature 브랜치에서 진행
2. 기능 개발이 완료되면 develop 브랜치에 feature 브랜치를 remote PR
3. develop 브랜치에서 release 브랜치를 생성 혹은 rebase 하고 배포 준비
4. release 브랜치에서 최종 로컬 테스트
5. 배포 준비가 완료되었을 때, release 브랜치를 master 브랜치에 remote PR + merge
6. master 브랜치에 릴리즈 버전 tag 추가 + remote push
7. 배포 서버에서 master 브랜치 pull 및 배포

버전 규칙

💪 모든 배포 시에 아래의 세 버전 중 하나는 반드시 1 증가된다.

• major version

  • 프로그램의 대폭적인 변경이 있을 경우

• minor verison

  • 기존 버전에 없던 기능이 생기거나, 기능 개선이 있을 경우

• patch version

  • 자잘한 버그 수정이나 내부적 코드 보완이 있을 경우. 작은 수정이라도 새로 배포될 경우 patch version 을 증가시킨다.

• github issue 에서 배포 버전을 명시하는 label 은 불필요하다.