출시 노트 관리

OSS 변경 로그 또는 릴리스 정보를 어떻게 관리합니까?



나 자신은 요즘 CHANGELOG 파일을 사용하지 않고 거의 독점적으로 GitHub Releases를 사용합니다.

여기에는 3가지 주요 이유가 있습니다.

수백 개의 저장소를 관리하는 것이 점점 더 어려워지고 있음

GitHub 릴리스가 개선되고 있음

대규모 프로젝트에서 CHANGELOG가 충돌하는 경향이 있음

릴리즈 노트

GitHub에는 ability to automatically generate releases notes이 있습니다.

이 기능은 현재 버전과 병합된 풀 요청을 요약합니다. 각 풀 요청에 대한 링크, 작성자 이름 및 해당 버전의 기여자 목록이 포함되어 있기 때문에 매우 유용합니다. 이것을 직접 생성하려고 하면 쉽지 않습니다. 무엇보다 GitHub에서 이 기능을 공식적으로 제공한다는 점이 마음에 듭니다.
.github/release.yml 를 입력하면 풀 리퀘스트에 붙은 라벨에 따라 별도의 섹션도 생성한다. 나는 keep-a-changelog과 같은 형식을 좋아하기 때문에 다음 6개의 레이블을 준비했습니다.

더하다

변경

지원 중단

수정

제거하다

보안

기본적으로 이러한 레이블은 리뷰할 때 추가하지만 잊어버리더라도 출시 전에 추가할 수 있습니다.

레이블

각 리포지토리에 이러한 레이블을 수작업으로 준비하는 것은 번거롭기 때문에 github-label-sync-action 을 사용하여 자동화했습니다. .github/labels.yml에 각 레이블의 이름, 설명, 색상을 입력하면 자동으로 GitHub에 동기화됩니다.

또한 이 구성 YAML 파일을 준비하는 프로세스를 자동화하고 싶기 때문에 이를 위해 r7kamura/github-keepachangelog-template을 생성하고 gitcp을 사용하여 현재 디렉터리에 복사합니다.

gitcp r7kamura/github-keepachangelog-template

워크플로우

요즘에는 GitHub Actions를 사용하여 태그 및 릴리스와 같은 새 버전을 게시하는 프로세스를 자동화합니다. 예를 들어 npm 패키지의 경우 version 에 manifest.json 를 넣습니다. 버전 변경을 감지하고 새 Git 태그, 새 GitHub 릴리스 등을 자동으로 생성하는 워크플로가 있습니다.

각 리포지토리에 대해 이러한 워크플로를 준비하는 데 시간이 많이 걸리므로 Reusable workflows을 사용하고 r7kamura/workflows에서 자체 워크플로를 구성합니다.

다음은 vscode-ruby-light에서 내 VSCode 확장을 릴리스하는 예제 워크플로입니다.

name: release

on:
  push:
    branches:
      - main

jobs:
  release:
    uses: r7kamura/workflows/.github/workflows/vscode-extension-release.yml@main
    secrets:
      vsce-token: ${{ secrets.VSCE_TOKEN }}

이것을 작성하고 package.json 및 git push의 버전 필드를 변경하면 자동으로 새 git 태그, 자동으로 생성된 릴리스 정보가 있는 새 GitHub 릴리스가 생성되고 확장이 빌드되며 VSCode 마켓플레이스에 게시됩니다.

마무리

릴리스 노트를 관리하는 방법에 대해 썼습니다.

릴리스 노트는 사용자에게 매우 중요한 정보 소스입니다. 그러나 유지 관리가 어려울 수 있음을 이해합니다. 비용을 들이지 않고 자동화하고 관리할 수 있으면 좋겠습니다.