버전 관리

목적

빙글 서버 어플리케이션의 변경사항에 대해 명확한 배포 기준점을 관리한다.
어플리케이션의 버전 관리가 우선되어야, 이를 기반으로 빙글의 컨테이너 이미지를 관리할 수 있다.

적절한 수단 알아보기

• Semantic Versioning
  • Major.Minor.Patch
  • 1.0.0 -> 1.0.1 (패치 1번)
  • Major -> 다바꿨음. 하위호환성 없음
  • Minor -> 기능 조금 추가됨
  • Patch -> 버그 수정함
• Calendar Versioning
  • 날짜로 구분이 되는 경우
  • 외부에 공개되는 프로젝트인 경우 마케팅적 의미가 있는 듯
    • Ubuntu의 경우 22.04.10 <- 이런식의 버저닝을 하고 있음
    • 이 버저닝을 통해 알 수 있는 것은 “아 이 배포판이 22년 4월 배포판이구나!” 정도,
  • Pros & Cons
    • (Pro) 최신인지 아닌지가 상대적으로 명확하다.
    • (Pro) 릴리즈 주기가 명확하다.
    • (Con) SemVer에서는 단순 패치(픽스)인지, 마이너 체인지(기능 추가) 인지, breaking changes 인지 직접적으로 알 수 있으나, CalVer은 그런 의미를 담기 어렵다.
    • (Con) 내부적인 버저닝을 사용하는 빙글에서 - 날짜 구분은 큰 의미를 갖지 못한다.

과정

배경 - 브랜치 전략

1. dev가 주 브랜치, 개발 환경은 dev 브랜치와 동기화된다.

2. main 브랜치는 주기적으로 dev 브랜치를 따라간다 (ff-merge)

   참고) Notion 문서 - ff-merge를 사용하는 이유

버저닝 전략 - Semantic Versioning

개발 환경도 배포가 이뤄져야 하므로, 각 커밋마다 버전을 부여한다. (기준은 추후 변경될 수 있음)
컨테이너 이미지는 부여된 버전을 따른다.

특성

• 커밋과 버전은 각각 1:1로 매칭되는 관계이다.

• 매 버전이 운영환경에 배포되는 것은 아닐 수 있다.

  ex) 1.0.1~1.0.11까지 운영 배포 없이 개발 후 → 운영 환경 버전을 한 번에 1.0.11로 올리는 경우