1. 들어가며
소프트웨어 버전 관리 규칙 - Semantic Versioning
1. 들어가며 Github에는 위와 같이 Releases라는 기능이 있어 소스코드의 결과물을 배포할 수 있는 기능을 제공하고 있다. 이전에는 해당 기능을 사용하지 않았지만, 이번 프로젝트부터는 릴리즈를
leeeeeyeon-dev.tistory.com
이전 포스트에서 Semantic Versioning과 Major, Minor, Patch 버전에 대해 간략히 알아보았다. 이번 포스트에서는 직접 Github Releases를 만들어보자.
2. Releases 만들기
첫 Release를 배포하는 경우
Create a new release를 눌러준다.
첫 Release가 아닌 경우
Releases > Draft a new release 버튼을 눌러준다.
3. Release Draft 작성하기
Choose a tag를 누른 후 현재 버전을 기입 혹은 선택해준다.
Generate release notes 버튼을 누르면 아래 사진처럼 이제까지의 커밋 기록, 커밋 작성자, PR 번호를 자동으로 작성해준다.
다른 분들의 레포를 봤을 때 주로 제목은 버전명, 내용에는 What's Changed로 구성하는 것이 일반적인 것 같았다.
추가적으로 적고 싶은 내용이 있다면 적고 Update a release 버튼을 눌러 릴리즈를 배포하면 끝난다.
4. Github Actions로 Release 작성 자동화하기
우리는 "개발자"니까 ...!!! 번거로운건 ! 자동화를 해보자 !
이번 목표는 main 브랜치로 PR을 머지했을 때 자동으로 Release Draft를 작성하는 것이다.
Release Drafter라는 Github Action을 사용하여 쉽게 할 수 있다.
Release Drafter는 PR을 기반으로 라벨링된 것을 판별해서 버전을 자동으로 업데이트해주는 액션이다.
GitHub - release-drafter/release-drafter: Drafts your next release notes as pull requests are merged into master.
Drafts your next release notes as pull requests are merged into master. - GitHub - release-drafter/release-drafter: Drafts your next release notes as pull requests are merged into master.
github.com
이것을 사용하기 위해서는 Release Drafter를 사용하기 위한 yml 파일과 Release Drafter 관련 설정들을 작성할 config yml 파일이 필요하다.
Github Actions 스크립트
나는 기존에 사용하던 CD 스크립트에 릴리즈 자동화 액션을 추가할 것이기 때문에 CD 스크립트 하단에 아래 코드를 추가해주었다.
Github Token이 없다면 Settings > Developer Settings > Personal access tokens에서 만들어주자. (+ workflow acess 허용하기)
- name: Update Release
uses: release-drafter/release-drafter@v5
with:
config-name: release-drafter-config.yml
env:
GITHUB_TOKEN: ${{ secrets.ACTION_TOKEN }}
만약 Github Actions 파일이 없다면 .github/worflows/release-drafter.yml 파일을 하나 만들고 아래 내용을 작성해주면 된다.
name: Release Drafter
on:
push:
branches:
- main
jobs:
update_release_draft:
runs-on: ubuntu-latest
steps:
- uses: release-drafter/release-drafter@v5
with:
config-name: release-drafter-config.yml
env:
GITHUB_TOKEN: ${{ secrets.ACTION_TOKEN }}
release-drafter-config.yml
with > config-name에 적은 release-drafter-config.yml 파일을 만들어준다.
release-drafter-config.yml 파일은 .github/workflows가 아니라 .github 폴더에 만들어준다.
name-template: 'v$RESOLVED_VERSION'
tag-template: 'v$RESOLVED_VERSION'
categories:
- title: '🎁 새로운 기능이 추가되었어요'
label: '🎁 feature'
- title: '🐞 자잘한 버그를 수정했어요'
label: '🔨 fix'
- title: '🐬 코드를 개선했어요'
label:
- '📋 docs'
- '🧼 refactor'
- '🪄 setting'
- '🎫 test'
- '🚀 deploy'
change-template: '- $TITLE #$NUMBER @$AUTHOR '
template: |
## 이번 버전의 변경사항은 아래와 같아요
---
$CHANGES
no-changes-template: '변경사항이 없어요'
version-resolver:
major:
labels:
- '✨ major'
minor:
labels:
- '✨ minor'
patch:
labels:
- '- '✨ patch'
default: patch
name-template, tag-template
Release title과 tag에 들어갈 내용을 적어준다.
- $NEXT_MAJOR_VERSION
- $NEXT_MINOR_VERSION
- $NEXT_PATCH_VERSION
- $RESOLVED_VERSION
위 네 가지 형식을 통해 어떤 버전을 올려줄지 고를 수 있다. $RESOLVED_VERSION은 version-resolver 옵션에서 정의한 레이블에 따라 버전을 올린다.
categories
PR에 붙어있는 라벨을 확인하여 title에 적힌 카테고리의 하위로 PR을 정의한다.
change-template
What's Changed에 적힌 텍스트의 형식을 지정할 수 있다.
version-resolver
PR에 붙어있는 라벨과 labels에 적힌 라벨이 일치하면 해당 버전으로 버저닝을 진행한다. PR 라벨을 활용하여 직접 버저닝을 진행하고 싶은 경우 적합하다.
이렇게 develop > main 브랜치로 PR을 만들 때 Label을 patch로 해두면 patch 버전이 업데이트된 것을 Draft에서 확인할 수 있다.
template, no-changes-template
Release Draft의 템플릿을 지정할 수 있다. no-changes-template은 change log가 없을 때 띄울 템플릿이다.
5. 자동화 결과
이렇게 자동으로 작성된 릴리즈는 바로 배포되는 것이 아니라 Releases 페이지에 Draft로 저장된다. Draft를 확인하여 원하던대로 작성되었다면 연필 아이콘을 눌러 편집 탭으로 들어간 뒤, Publish Releases 버튼을 눌러서 릴리즈를 마무리하면 된다 !!
