티스토리 뷰

Development

Semantic Versioning & Conventional Commit

신잼 2021. 12. 22. 17:49

Conveiontional Commit를 사용하면 commit 만으로 Sementic Versioning을 쉽게 할 수 있습니다.

mokkapps.de/blog/how-to-automatically-generate-a-helpful-changelog-from-your-git-commit-messages/ & dzangolab.com/tutorials/misc/semver/

fix 타입의 커밋은 PATCH 버전으로 번역
feat 형식 커밋은 MINOR 버전으로 번역
타입과 관계없이 BREAKING CHANGE를 포함한 커밋은 MAJOR로 번역

SemVer

Versioning

특정 상태에 대한 유일한 버전 이름 혹은 버전 번호를 각각 결정하는 과정이다. 소프트웨어의 관리를 위해 고안되었다

Semantic Versioning

Semenantic Versioning을 줄여서 SemVer로 부르며 유의적 버저닝으로 번역된다.
버전 번호를 어떻게 정하고 올려야 하는지에 대한 규칙과 요구사항이 담긴 명세로 Github의 공동 창업자인 Tom Preston-Werner가 제안하는 방법이다.
명시적인 정의를 내림으로써, 소프트웨어 사용자에게 제작자의 의도를 전달하기 쉬워진다.
의도가 명확하고 융통성 있는 의존성 명세를 만들 수 있다.

자세한 규칙은 spec 문서 통해 확인이 가능하다.

소프트웨어 생명 주기

Alpha, Beta, RC, RTM는 크게 테스트와 개발 단계에 있는 버전과 출시가 가능한 버전으로 구분된다.

Testing and Development

Alpha
- 보통 조직 내부적으로 이뤄지는 버전 테스트 시작 단계
- 기본적으로 white-box 테스트를 시행
- 충돌과 데이터 손실이 있을 수 있으며 최종 버전에 담기는 모든 기능이 없을 수 있다.
- 더 이상 기능이 추가되지 않을 때 alpha가 끝난다.
Beta
- 보통 public 한 사용자의 테스트로 이뤄지는 버전
- 기능 개발은 완료됐지만 어떤 문제가 있을지 모르는 단계
- 버그가 많을 수 있고 속도나 퍼포먼스에 이슈가 있으며 데이터 손실이나 충돌 발생 가능성이 있다
RC(Release Candidate)
- 최종 제품이 될 가능성이 있는 베타 버전으로, 심각한 버그가 발생하지 않는 한 출시할 준비가 되어 있다.
- 내부적으로 출시된 빌드로, 이전 개발 기간 동안 코드로 감지되지 않은 중요한 문제가 있는지 확인합니다. 릴리스 후보는 프로덕션 배포용이 아니라 테스트용이다
- 부하 테스트 등 모든 테스트 종류의 최종 단계가 이뤄진다.

Release

RTM(Release to Manufacturing)
- 소프트웨어가 고객에게 배송 및 제공될 준비가 되었음을 뜻하는 용어이다. 이 용어는 배송 구조나 배송량을 정의하지는 않으며, 단지 제품 품질이 대량 생산을 하기에 충분함을 정의한다.

Conventional commit

깃 커밋 메시지 컨벤션은 다양할 수 있습니다. 그중에서 많이 사용되고 있는 conventional commit과 Angular 컨벤션입니다.

메시지 구조(Commit Message Format)

<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

<header>

<type>(<scope>)!: <short summary>
  │       │             │
  │       │             └─⫸ Summary in present tense. Not capitalized. No period at the end.
  │       │
  │       └─⫸ Commit Scope: animations|bazel|benchpress|common|compiler|compiler-cli|core|
  │                          elements|forms|http|language-service|localize|platform-browser|
  │                          platform-browser-dynamic|platform-server|router|service-worker|
  │                          upgrade|zone.js|packaging|changelog|docs-infra|migrations|ngcc|ve
  │
  └─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test

<type>

build: 빌드 시스템이나 외부 종속성에 영향을 주는 변경사항 i.e. gulp, broccoli, npm
ci: ci 구성 파일 및 스크립트 변경사항 i.e. CircleCi, SauceLabs
docs: Documentation의 변경사항 only
feat: 새로운 기능
fix: 버그 수정
perf: 성능 개선을 위한 코드 수정
refactor: 버그를 수정하거나 기능을 추가하지 않는 코드 변경, 리팩터링
test: 테스트 추가 또는 기존 테스트 수정
revert: 커밋 취소, revert: <취소된 커밋 헤더>
- 바디에 revert 되는 commit SHA를 적는다. i.e. This reverts commit <SHA>
- 바디에 왜 취소하는지에 대한 명료한 설명

<scope>

코드 베이스가 적용되는 영역을 기술한다. 패키지 및 모듈 이름이 들어간다.
- i. e. fix(parser): array parsing issue when multiple spaces were contained in string
패키지 및 모듈이 아닌 예외 케이스를 지정할 수 있다.

!

breaking change가 있을 때 붙여 준다.! 가 있으면 Footer의 BREAKING CHANGE를 생략할 수 있다.

feat!: send an email to the customer when a product is shipped

<summary>

변경사항에 대한 간략한 설명 제공

명령조, 현재 시제 사용 i.e. change not changed or changes
첫 문자는 소문자로 시작
마지막은 점(.)으로 끝날 수 없다.

<Body>

형식이 자유롭고 여러 단락으로 구성 가능하다
summary와 같이 명령조, 현재 시제 사용 i.e. fix not fixed or fixes
변경에 대한 동기를 설명, 왜 수정했는지
이전 버전과 비교하여 어떤 추가기 있었고 어떤 영향을 주는지 설명할 수 있다.

<Footer>

큰 변화에 대한 정보(breaking changes)나 없어진 기능(deprecated)을 포함할 수 있다. 또한 Github issue나 Jira ticket 등 PR에 대한 레퍼런스를 closes나 realted to 등과 함께 위치할 수 있다.

BREAKING CHANGE: <breaking change summary>
<BLANK LINE>
<breaking change description + migration instructions>
<BLANK LINE>
<BLANK LINE>
Fixes #<issue number>

DEPRECATED: <what is deprecated>
<BLANK LINE>
<deprecation description + recommended update path>
<BLANK LINE>
<BLANK LINE>
Closes #<pr number>

Conventional Commit 사용 이점

CHANGELOG를 자동으로 생성하기 위해서
(포함된 커밋의 타입에 기반하여) 유의적 버전(Sementic Versioning)을 자동으로 변경하기 위해서
변경 사항을 보다 명료하게 전달하기 위해서
빌드와 배포 프로세스 수행하기 위해서
더 구조화된 커밋 히스토리를 보여줘서 사람들이 프로젝트 참여 용이

도움이 되는 친구들

commit과 versioning에 도움에 활용할 수 있는 방법들을 소개합니다.

git commit template

commit 할 때마다 내용을 볼 수 있도록 템플릿을 저장해둘 수 있다.

commitizen

일종의 cli tool로 conventional commit에 맞춰 type들을 선택할 수 있게 해주는 utility

python버전과 js 버전이 있다.

python 버전을 사용하고 있다.
- git action이 잘 되어 있다
- js 스택 프로젝트를 하지 않는다.
- 문서가 잘 나와 있고 설정이 조금 더 유연하다
- 사용 방법 참고

Commitlint

conventional commit 규칙을 위반하는지 체크 해주는 linter

pre-commit 활용

commit message를 잘못 작성하면 commit 전에 검사를 해주는 github hook을 설정해줄 수 있다.

// .pre-commit-config.yaml

default_stages:
- commit

repos:
- hooks:
  - id: commitizen
    stages:
    - commit-msg
  repo: https://github.com/commitizen-tools/commitizen
  rev: v2.20.0

github aciton 활용

github action에 commit linter를 추가해서 lint를 할 수 있다.

// .github/workflows/commitlint.yml

name: Lint Commit Messages

on:
  push:
    branches: [ "develop" ]

  pull_request:
    branches: [ "develop" ]

jobs:
  commitlint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - uses: wagoid/commitlint-github-action@v4

Changelog

꼭 필요하지 않은 기능이지만 사용하고 있는 commitizen tools에서 버전 업과 함께 쉽게 제공이 되고 있기 때문에 main 브랜치로 release 될 때 생성될 수 있게 활용하고 있다.

// .github/workflows/release.yml

name: Release

on:
  push:
    branches:
      - main

jobs:
  release:
    if: "!startsWith(github.event.head_commit.message, 'bump:')"
    runs-on: ubuntu-latest
    name: "Bump version and create changelog with commitizen"
    steps:
      # Bump version and make changelog
      # REF: https://github.com/marketplace/actions/bump-and-changelog-using-commitizen
      - 
        name: Check out
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
          token: "${{ secrets.GH_TOKEN }}"
      - 
        id: cz
        name: Create bump and changelog
        uses: commitizen-tools/commitizen-action@master
        with:
          github_token: ${{ secrets.GH_TOKEN }}
          branch: main

//.cz.toml

[tool.commitizen]
name = "cz_conventional_commits"
version = "0.0.1"
version_files = [
    ".cz.toml:version"
]
tag_format = "v$version"
update_changelog_on_bump = true

Release

github의 release도 commit tools 해서 제공해주지만 goreleaser를 사용하고 있다. go로 작성된 프로젝트에서 os별로 실행 파일을 만들어 주는 부분이 맘에 들었다.

// .github/workflows/release.yml

...
      -
        name: Run GoReleaser
        uses: goreleaser/goreleaser-action@v2
        with:
          # either 'goreleaser' (default) or 'goreleaser-pro'
          distribution: goreleaser
          version: latest
          args: release --rm-dist
        env:
          GITHUB_TOKEN: ${{ secrets.GH_TOKEN }}

tellme.tokyo/post/2020/02/04/release-go-cli-tool

Reference

저작자표시 비영리 변경금지 (새창열림)

'Development' 카테고리의 다른 글

k8s 공부 하면서 헷갈렸던 용어 정리 (0)	2022.02.21
docker compose VS docker-compose (0)	2022.02.17
환경변수 관리 하기(direnv, dotenv) (0)	2021.12.14
Concurrent requests in go and python (0)	2021.12.06
[Test]유닛 테스트(Unit Test) vs 통합 테스트(Integration Test) vs 기능 테스트(Functional Test) (0)	2021.11.11

공지사항

최근에 올라온 글

최근에 달린 댓글

Total

Today

Yesterday

링크

TAG more

« 2025/11 »
일	월	화	수	목	금	토
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30

글 보관함

잼있는 블로그

티스토리 뷰

Semantic Versioning & Conventional Commit

SemVer

Versioning

Semantic Versioning

소프트웨어 생명 주기

Testing and Development

Release

Conventional commit

메시지 구조(Commit Message Format)

<header>

<type>

<scope>

!

<summary>

<Body>

<Footer>

Conventional Commit 사용 이점

도움이 되는 친구들

git commit template

commitizen

Commitlint

pre-commit 활용

github aciton 활용

Changelog

Release

Reference

'Development' 카테고리의 다른 글

티스토리툴바