[Project] 포트폴리오 제작기 -3. Release Note Draft 자동화하기

young_pallete·2022년 11월 24일
1

🚦시작하며

남들 몰래 포트폴리오를 만들면서, 저는 한 번 release note를 활용해볼까 하는 기대가 있었어요.

왜냐하면, 본질적으로 어떻게 배포되었는지를 설명해주는 건 유저의 입장에서 달라진 점을 이해하기 편하기 때문이죠.

하지만 여간 귀찮습니다.
적어도, 계속해서 일일이 똑같은 컨벤션을 유지하며 글을 작성한다는 것은, 반복된 일을 싫어하는 개발자들에겐 분명 힘든 고통이 생기기 때문이죠. 😭

그래서 저는 릴리즈 노트를 배포하기 전, 양식을 자동화를 하기 위한 방법을 찾았어요.
어떻게 릴리즈 노트를 자동화할 수 있었는지 한 번, 살펴보죠!

🚀 본론

GitHub Actions - release drafter

릴리즈 노트에 관한 워크플로우를 간단히 설정할 수 있는 Release Drafter GitHub Action라는 것이 있었어요.

이 친구는 PR을 기반으로 라벨링된 것을 판별해서, 버전을 자동 업데이트해주는데요.
저는 원래 PR을 기반으로 프로젝트를 진행하기 때문에 저에게 너무 안성맞춤이라 사용했어요.

.github/workflows/release-drafter.yml

따라서 여기서 주요 설정들을 확인해보며, 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.PERSONAL_TOKEN }}

그런데 이게 끝이 아니에요. 이 친구가 어떤 컨벤션을 만들었는지 참고하는 yml 파일이 또 존재해야 합니다. 그 친구가 with -> config-name에 존재하는 release-drafter-config.yml 파일이에요.

.github/release-drafter-config.yml

name-template: '🚀 v$RESOLVED_VERSION'
tag-template: 'v$RESOLVED_VERSION'
categories:
  - title: '💡 Features'
    labels:
      - '🌈 Feature'
  - title: '🐛 Bug fixes'
    labels:
      - '⚠️ Bug'
  - title: '🤯 Inner Changes'
    labels:
      - '📦 Chore'
      - '📃 Docs'
change-template: '- $TITLE #$NUMBER @$AUTHOR '
change-title-escapes: '\<*_&'
version-resolver:
  major:
    labels:
      - 'major'
  minor:
    labels:
      - 'minor'
  patch:
    labels:
      - 'patch'
  default: patch
template: |
  ## 🚀 이번 버전에서는 어떤 게 바뀌었을까요?
  ---
  $CHANGES
no-changes-template: '앗! 변경사항이 없어요. 😖'

여기서 저는 다음과 같은 컨벤션을 세웠어요.

컨벤션 내용 1. 라벨에 따른 카테고리 분류

  • 🌈 Feature이라는 라벨이 붙으면 💡 Features라는 카테고리 하위로 PR을 정의한다.
  • ⚠️ Bug라는 라벨이 붙으면 🐛 Bug fixes라는 카테고리 하위로 PR을 정의한다.
  • 📦 Chore📃 Docs인 라벨은 🤯 Inner Changes 카테고리 하위로 PR을 정의한다.

컨벤션 내용 2. 라벨에 따른 배포 분류

그럼 버저닝도 해야되겠죠? 실제로 이 친구는 버저닝도 자동화해줍니다.
위의 라벨들로 자동으로 버저닝할 수도 있지만, 저는 직접 제가 판단해서 버저닝하고 싶었어요.

따라서 다음과 같이 라벨로 배포 분류를 만든 다음, develop -> main으로 PR할 때 라벨로 버저닝하는 방식을 채택했습니다. 이는 위의 version-resolver을 통해 가능해요.

  • major 라벨이 붙은 다음, main에 푸시하면 메이저 버전이 올라가요.
  • minor 라벨이 붙은 다음, main에 푸시하면 마이너 버전이 올라가요.
  • patch 라벨이 붙은 다음, main에 푸시하면 패치 버전이 올라가요.

어때요. 간단하죠?

템플릿 설정

template에서 관리가 가능해요.

template: |
  ## 🚀 이번 버전에서는 어떤 게 바뀌었을까요?
  ---
  $CHANGES

이때, 만약 변경사항이 없을 수도 있죠! 그러면 디폴트를 만들어줄 수도 있어요.

no-changes-template: '앗! 변경사항이 없어요. 😖'

결과

요론 식으로 배포 후 설정할 버전을 고려하여 라벨링을 해줘요.
저는 피쳐 단위로 작업한 게 많아서, 마이너 버전을 올렸어요.

다음과 같이 초안이 일정한 컨벤션을 바탕으로 나와요.
이를 수정하여 다시 상세사항을 작성하고, 퍼블리시하면 됩니다. 🥰

🎉 마치며

그렇지만 갑자기 말씀드리지만... 저는 이제 이 방법을 사용하지 않습니다!
이유는, 정말 몰래 포트폴리오 사이트를 만들고 있었는데요.
릴리즈 노트를 배포하는 순간, 모든 팔로잉한 사람들에게 알림이 갑니다 😭
덕분에 강제 공개(?)를 당한 것을 알게된 지금, CHANGELOG.md로 갈아탔습니다.

아~무도 모르게 은밀한 작업을 하시는 분이 계시나요?
그렇다면 릴리즈 노트보다는, 체인지 로그와 자동 버저닝에 대한 다른 방법을 고려하시는 게 더 나은 선택일 수도 있겠네요. 😖

하지만, 나중에 실제 앱을 운영한다면 이 방법은 분명 강력하다고 말씀드리고 싶군요!
그리고 이 자동화 과정은 분명 편리하고 재밌었어요.
누군가에겐 도움이 되길 바라며. 이상! 🌈

profile
People are scared of falling to the bottom but born from there. What they've lost is nth. 😉

0개의 댓글