티스토리 뷰

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는 크게 테스트와 개발 단계에 있는 버전과 출시가 가능한 버전으로 구분된다.

ko.wikipedia.org/wiki/소프트웨어_배포_생명_주기

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 할 때마다 내용을 볼 수 있도록 템플릿을 저장해둘 수 있다.

merrily-code.tistory.com/54

commitizen

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

commitizen-tools.github.io/commitizen

  • 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
«   2024/05   »
일 월 화 수 목 금 토
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 31
글 보관함