1. Intro
기존에 릴리즈 노트를 작성할 때 Github 에서는 자동으로 release 내역을 작성해주는 기능이 있습니다. 아래와 같이 Generate release notes 를 활용하면, 지금까지 merge 된 Pull Request를 가져와 릴리즈 노트를 생성해줍니다. 하지만 이러한 작업 역시 손으로, 수동으로 이루어지기 때문에 릴리즈가 자주 일어나거나, 릴리즈 노트 관리를 깜빡할 경우 관리 이슈가 발생할 수 있습니다.
그리고 이렇게 생성된 release note는 생각보다 그렇게 가독성이 좋지 않은 것을 알 수 있습니다. 아래의 예제 그림처럼 기본 기능을 수동으로 활용하게 되면, 지금까지의 PR이 순서대로 정렬되어 가독성이 좋지 않은 목록들이 나열됩니다.
Github를 활용하여 프로젝트를 진행하면서, Pull Request를 세심히 관리하고 develop 브랜치에 1차적으로 검증된 코드가 merge 됩니다. 이 과정에서도 상당한 노력이 드는데요. 하지만 막상 릴리즈 시점에 어떤 변경사항이 있는지 추적이 되지 않거나 , 가독성이 좋지 않은 PR 목록을 맞이하게 됩니다. 결과적으로 릴리즈 노트를 보고 어떤 작업이 이루어졌는지 확인하기 어렵고, 릴리즈 노트의 역할을 제대로 발휘하지 못하게 된다고 생각했습니다.
Auto creation
릴리즈 노트를 작성하기 전, PR 요청 및 merge 과정에서 상당한 노력을 쏟게 되는데요. 이 과정에 조그마한 장치를 추가하여 릴리즈 노트 시점에 적절한 작업 목록을 자동으로 생성할 수 있도록 하면 어떨까 하는 생각을 해보았습니다.
•
feature 기능을 develop 브랜치로 merge할 때 어떤 작업인지(feature, fix, chore)
•
release 시점에 이러한 label을 활용하여 어떤 작업이 이루어졌는지 확인
•
release 노트는 자동으로 생성
이와 같은 요구사항을 만족하기 위해 Github Action의 괜찮은 기능을 찾아보았습니다.
Release drafter
Github Action 레포지토리 중 release-drafter라는 것을 발견하였습니다. 제가 생각하는 릴리즈 노트 자동 생성에 가장 적절한 기능을 가지고 있으며, steps을 설정할 때 복잡하지 않았습니다.
2. Workflows
릴리즈 노트 자동으로 생성해주는 workflows는 template과 github action 두 가지로 구분됩니다.
workflows - drafter.yaml
release-drafter를 활용하여 릴리즈 노트를 자동으로 생성해줍니다.
•
main 브랜치에 push 시 아래의 jobs가 실행됨
•
release-drafter를 사용하되, config는 .github/drafter-config.yaml 파일을 활용함
# .github/workflows/drafter.yaml
name: Draft new release
on:
push:
branches:
- main
jobs:
build:
permissions:
contents: write
pull-requests: write
runs-on: ubuntu-latest
steps:
- name: Release
# reference : https://github.com/release-drafter/release-drafter
uses: release-drafter/release-drafter@v6
with:
config-name: drafter-config.yaml
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
YAML
복사
template - drafter-config.yaml
Draft 문서를 만드는 Template입니다. 여기서 commitish는 default가 master이기 때문에 main 브랜치로 변경해주었고, 각각 카테고리별 문서를 자동으로 생성해주기 위해 label로 구분할 수 있습니다.
name-template: 'v$RESOLVED_VERSION 🌈'
tag-template: 'v$RESOLVED_VERSION'
commitish: main
categories:
- title: '🚀 Features'
labels:
- 'feature'
- 'enhancement'
- title: '🐛 Bug Fixes'
labels:
- 'fix'
- 'bugfix'
- 'bug'
- title: '🧰 Maintenance'
label: 'chore'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
change-title-escapes: '\<*_&' # You can add # and @ to disable mentions, and add ` to disable code blocks.
version-resolver:
major:
labels:
- 'major'
minor:
labels:
- 'minor'
patch:
labels:
- 'patch'
default: patch
template: |
## Changes
$CHANGES
YAML
복사
categories
•
라벨이 feature, enhancement로 돼 있는 PR은 릴리즈 노트 작성 시 
Features 아래에 작성됨
Features 아래에 작성됨◦
새로운 기능을 추가할 경우
◦
기존의 기능을 삭제할 경우
◦
기존의 기능을 수정할 경우
•
라벨이 fix, bugfix, bug로 돼 있는 PR은 릴리즈 노트 작성 시 Bug Fixes 아래에 작성됨
Bug Fixes 아래에 작성됨◦
추가하거나 기존의 기능이 버그를 일으켜 수정할 경우
•
라벨이 chore로 돼 있는 PR은 릴리즈 노트 작성 시 Maintenance 아래에 작성됨
Maintenance 아래에 작성됨◦
코드와 관계 없이 README 등 옵션을 추가해줄 경우
◦
github action 추가하는 경우도 동일
commitsh
•
default : master
•
기준이 되는 브랜치를 설정함
version-resolver
마지막으로 작성된 tag의 버전을 기준으로 아래의 기능이 수행됩니다.
•
라벨이 major일 경우 major 버전을 올리고 minor, patch 버전을 0으로 초기화함
•
라벨이 minor일 경우 minor 버전을 올리고 patch 버전을 0으로 초기화함
•
라벨이 patch일 경우 patch 버전을 올림
template
릴리즈 노트를 작성하는 기본 템플릿입니다. 릴리즈 노트 작성 시 ## Changes 아래에 자동으로 생성되는 문서를 생성해줍니다.
Warning
릴리즈 노트 생성 시 유의사항이 있습니다. 만약 release 노트 작성 시 tag가 없을 경우 가장 처음 버전은 v0.1.0을 생성해줍니다. 단, 생성된 문서는 draft 문서이기 때문에 필요하다면, 수정하여 관리가 가능합니다.
3. Usage
릴리즈 노트를 자동으로 생성하기 위해서는 다음과 같은 프로세스로 하는 것을 추천드립니다.
1.
feature 브랜치를 생성 후 개발 작업 완료
2.
feature → develop 으로 merge 하는 Pull Request 생성 후 merge
3.
1 ~ 2 과정을 반복
4.
만약 릴리즈를 할 경우 develop 브랜치를 기준으로 새로운 release/x.y.z 브랜치를 생성함
a.
이때 릴리즈 브랜치의 이름은 관계 없으나 가독성을 위해 버전을 작성함
b.
버전 뒤에 어떤 글이 있어도 무방함 (버전 관리는 tag 기준)
5.
release/x.y.z 브랜치를 기준으로 추가할 작업이 있다면 feature → develop → 생성한 release 브랜치에 merge
6.
더 추가할 작업이 없다면 release → main 으로 merge 하는 Pull Request 생성
7.
merge 하면 release 노트 작성
4. Example
release 노트를 작성하는 예제를 만들어 Github 예제를 작성해보았습니다. closed 된 Pull Request와 아직 지우지 않은 release 브랜치를 확인하면 도움이 될 것 같습니다.
