콘텐츠로 이동
Evo Docs

릴리스 절차

원천 · framework/evomind/web/workflow-project-evo-dispatch기준 · 릴리스 v0.1.0커밋 · 734af815파일 · docs/operations/release.md기준선 · 2026-11-12

evo-service docs/operations/release.md(§2.5)의 버전 정책 가운데 이 저장소에 필요한 만큼만 따른다: SemVer + git 태그 + backend/gradle.properties 명시, 태그 일치 CI 검증.

버전 정책

섹션 제목: “버전 정책”
종류 형식 만드는 곳 산출물
릴리스 X.Y.Z (git 태그 vX.Y.Z) develop → main 병합 뒤 main 에 태그 push git 태그·GitLab Release. 이미지·번들은 아직 만들지 않는다
develop 빌드 X.Y.Z-SNAPSHOT, 이미지 X.Y.Z-dev.<commit short SHA> develop push 시 자동 개발 서버 배포 이미지(개발 서버만 있다)
  • 브랜치 역할: main = 릴리스(태그 vX.Y.Z), develop = 개발 배포용. 기능 브랜치는 develop 에서 따고 MR 대상도 develop 이다.
  • develop 의 appVersion 은 X.Y.Z-SNAPSHOT, main 의 appVersion 은 X.Y.Z(태그와 같다)다.
  • 릴리스 이미지는 latest 태그를 만들지 않는다. 이 저장소에는 운영 서버가 없으므로 릴리스는 태그·Release 노트까지다.

버전 올림 규칙

섹션 제목: “버전 올림 규칙”
변경 올리는 자리 예
기능 추가가 하나라도 있다 마이너 X.(Y+1).0 0.1.7 → 0.2.0
버그 수정·문서·내부 정리만 있다 패치 X.Y.(Z+1) 0.1.6 → 0.1.7
  • 1.0 전에는 호환이 깨지는 변경(설정 이름 변경, API 제거 등)도 마이너로 올리고 Release 노트에 적는다.
  • 릴리스 뒤 develop 은 다음 버전 X.Y.(Z+1)-SNAPSHOT 으로 둔다. 기능이 develop 에 처음 들어가는 MR 에서 X.(Y+1).0-SNAPSHOT 으로 올린다.

릴리스 순서

섹션 제목: “릴리스 순서”
  1. develop 브랜치에서 backend/gradle.properties 의 appVersion 에서 -SNAPSHOT 을 뗀다(X.Y.Z). 버전은 위 표로 고른다.
  2. develop → main MR 을 만들어 병합한다. MR 본문에 이번 릴리스에 들어가는 변경(Issue·MR)을 적는다.
  3. main 에서 태그를 만든다: git tag vX.Y.Z && git push origin vX.Y.Z
  4. 태그 파이프라인이 release_version_check(태그 = appVersion) → backend_build·release_scripts_test·development_routing_validation 순으로 실행된다. 태그와 appVersion 이 다르면 첫 단계에서 실패한다.
  5. GitLab Release 를 만든다(glab release create vX.Y.Z --notes-file <파일>). 노트는 사용자에게 보이는 변경을 짧게 적고, 내부 주소·계정·비밀은 넣지 않는다.
  6. develop 의 appVersion 을 다음 버전 X.Y.(Z+1)-SNAPSHOT 으로 올려 MR 로 병합한다.

릴리스(태그 생성·push)와 배포는 승인된 사람만 수행한다. CI 성공은 릴리스 승인이 아니다.

검증

섹션 제목: “검증”
  • sh scripts/release/test-version.sh — 태그·appVersion·dev 이미지 태그 형식 회귀 시험(CI release_scripts_test).
    • version.sh release <tag>: 태그가 vX.Y.Z 가 아니거나, appVersion 이 X.Y.Z 가 아니거나(예: -SNAPSHOT), 둘이 다르면 실패한다.
    • version.sh dev <sha>: 개발 이미지 태그 <X.Y.Z>-dev.<sha> 를 만든다.
  • 태그 파이프라인은 배포·이미지 job 을 만들지 않는다(.default_rules 의 태그 조건은 빌드·시험 job 에만 붙고, dev_image·deploy_dev 는 develop 조건이다).

사전 조건

섹션 제목: “사전 조건”
  • 이 문서의 절차는 CI/CD 변수를 쓰지 않는다(태그 검증·빌드·시험만 한다). 개발 서버 배포 변수는 .gitlab-ci.yml 주석과 deploy/README.md 를 따른다.
  • 러너는 protected 로 등록해 보호된 브랜치·태그 파이프라인에서만 쓰이게 한다(관리자 설정).