[blog - 11] 블로그 버전 관리 및 배포 자동화 가이드

현재 개발 블로그의 버전 관리는 GitHub Actions를 통해 master 브랜치에 merge되었을 때 버전이 올라가도록 되어있다. 만약 현재 버전이 0.1.0일 때 PR 제목에 v1.0.0이라고 적으면, v1.0.0이라는 이름으로 깃허브 태그가 생성되고 이를 바탕으로 배포가 이루어지는 구조였다.

초기에는 체감하지 못했지만, 점차 버전 관리가 제대로 되지 않는 문제가 발생했다. 그 이유는 크게 두 가지다.

명확한 시맨틱 버저닝(Semantic Versioning) 규칙이 부재했다.
버전 관리 프로세스가 완전히 자동화되지 않았다.

이 문제를 해결하기 위해 명확한 버저닝 규칙을 세우고, 이를 바탕으로 완전한 자동화 환경을 구축했다. 아래는 새롭게 정립한 블로그 버전 관리 및 배포 가이드다.

1. 블로그 시맨틱 버저닝 (Semantic Versioning) 규칙

일반적인 소프트웨어 기준을 블로그 환경(기능 개발 + 콘텐츠 작성)에 맞게 재정의하여 사용한다.

🚀 MAJOR (주 버전) : v1.0.0

기존 사용자 경험이나 시스템 구조에 호환되지 않는 큰 변화가 생겼을 때 올린다.

적용 예시:
- 블로그 전체 UI/UX 대대적인 리뉴얼
- 코어 프레임워크 변경 (예: Jekyll -> Next.js, React -> Vue 등)
- 라우팅(URL) 구조가 완전히 바뀌어서 기존에 공유된 글 링크들이 깨지는 등 대대적인 마이그레이션이 발생할 때

✨ MINOR (부 버전) : v1.1.0

기존 구조를 유지하면서 **새로운 기능이나 굵직한 변화가 추가(콘텐츠 추가 포함)**되었을 때 올린다.

적용 예시:
- 새로운 블로그 글 추가 (포스팅)
- 새로운 기능 추가 (예: 다크/라이트 모드, 검색 기능, 댓글 시스템 도입, 목차(TOC) 기능 등)
- 새로운 카테고리나 메인 페이지 내 새로운 섹션 신설
- Google Analytics 등 새로운 외부 연동 추가
- SEO(검색 엔진 최적화) 대규모 개선

🩹 PATCH (수 버전) : v1.1.1

기존 기능의 버그를 수정하거나 아주 사소한 변경이 일어났을 때 올린다.

적용 예시:
- 모바일 환경에서 UI가 깨지는 현상 등 버그 수정
- 폰트 크기, 여백, 색상 등 간단한 CSS 디자인 수정
- 사용 중인 라이브러리(패키지)의 보안 업데이트 및 버전업

2. 커밋 및 PR 제목 작성 컨벤션 (자동 버전업)

위 버저닝 규칙을 자동화하기 위해, 작업 완료 후 master 브랜치로 병합할 때 아래 규칙에 맞게 제목을 작성해야 한다. (Squash and Merge 사용 시 PR 제목이 기준이 된다.)

feat!: 또는 본문에 BREAKING CHANGE 포함 👉 MAJOR (주 버전) 상승
- 대대적인 리뉴얼 및 프레임워크 교체
feat: 👉 MINOR (부 버전) 상승
- 새로운 기능 추가, 카테고리 신설, SEO 개선 등
fix: (또는 PATCH 트리거로 설정된 접두사) 👉 PATCH (수 버전) 상승
- 오타 수정, 버그 수정, CSS 수정 등

배포 프로세스: > 커밋 머지 👉 봇이 Release PR 자동 생성 👉 사용자가 Release PR 머지 👉 버전 태그 생성 및 Vercel 자동 배포

3. 수동으로 버전을 임의 지정하는 방법 (Manual Override)

자동 계산 규칙을 무시하고, 마케팅 목적이나 대규모 개편으로 인해 특정 버전(예: v2.0.0)으로 강제 점프해야 할 때는 다음 방법을 사용한다.

master 브랜치에 있는 package.json 파일의 "version" 숫자를 원하는 번호로 직접 덮어쓰고 커밋한다.
master에 병합되면, 봇은 변경된 package.json의 버전을 기준으로 알아서 릴리스 PR을 생성한다.