PRマージごとにDraftリリースノートを自動生成する
はじめに
特定のブランチにPRがマージされたタイミングで、Draftのリリースノートを自動で生成する方法のまとめです。
背景
現在、私はモバイルアプリ開発をgitflowで進めています。
下記のようなブランチを取り扱っており、一定期間developに実装コードを貯めたのち、最終的にmasterにまとまった対応がマージされるという流れになっています。
- master
- デリバリー済みのコードのみが含まれるブランチ
- release
- リリース作業用のブランチ
- develop
- 開発が完了した次のリリースのための実装コードがマージされていくブランチ
- feature/bugfix/refactor/...
- developから派生して各機能開発を進めていくブランチ
このフローで、masterとdevelopには実装コードに大きく差分ができることが多く、「masterにはどこまで対応が入っているか(どこまでリリースされているか)」 「どのバージョンにどの対応が入っているか」 を管理するのが大変になってくることがあります。
過去の開発フローでは、PMやエンジニアが手動でリリースIssueをリスト化したドキュメントを用意したりもしていましたが、このフローでは漏れや間違いなども増えてしまうので、システム的にこの問題を解決したいと考えました。
やりたいこと
developブランチに各開発ブランチで行った対応がマージされると、自動で対応した内容が列挙されたドキュメントが生成される。
実現方法の選定
1. GitHubの標準機能
まず結論として、この方法は選択しませんでした。
GitHubでは、下記のようにリリースノートを自動生成できる便利な機能が存在します。
これは準備が全く必要ないため最も簡単に使えるものではあるのですが、イベントのフックによる自動実行には対応していなさそうで、内容を更新したい場合はGitHubのWebページから手動で更新作業をする必要がありました。
(正確には半自動という感じで、ボタンをポチり直すことで最新化することができます。)
これだけでも便利ではあるのですが、開発スプリントの中で、「今どこまで入ってるんだっけ?」というのをささっと確認したい時に、毎回手動での更新作業をするのは面倒ですし、忘れる可能性もあります。そこで別の方法を検討することにしました。
2. release-drafter
PRマージでリリースノートを自動更新するためのツールを探している中で、下記のrelease-drafterというライブラリを見つけました。
このライブラリは、「GitHub Actions用のワークフローテンプレート」と「設定用のテンプレートファイル」をそれぞれyamlファイルで定義しておくだけで、リリースノートの自動生成を簡単に実現できます。
GitHubの自動生成では実現できなそうであった、完全自動でのワークフローが構築できそうだったため、今回はこちらを用いることにしました。
設定
GitHub Actions用の設定
今回はdevelopブランチへのマージをフックとしたいため、branchesの指定を develop
にしています。
最低限必要な設定はこれだけで、あとはリポジトリのルートから .github/workflows/release-drafter.yml
に設定ファイルを置いておきます。
name: Release Drafter
on:
push:
branches:
- develop
pull_request:
types: [opened, reopened, synchronize]
permissions:
contents: read
jobs:
update_release_draft:
permissions:
contents: write
pull-requests: write
runs-on: ubuntu-latest
steps:
- uses: release-drafter/release-drafter@v5
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
詳細については、こちらをご覧ください。
release-drafter用の設定
release-drafterを利用する場合、GitHub Actions用のyamlファイルだけではなく、release-drafterのconfigurationを行う専用の設定ファイルも必要となります。
こちらはリポジトリのルートから .github/release-drafter.yml
という名前でセットしておきます。
今回のプロジェクトでは以下のような設定を行いました。
name-template: '🍏 $RESOLVED_VERSION'
tag-template: '$RESOLVED_VERSION'
categories:
- title: '🚀 Features'
labels:
- 'feature'
- 'enhancement'
- title: '🐛 Bug Fixes'
labels:
- 'fix'
- 'bugfix'
- 'bug'
- title: '🧰 Maintenance'
label: 'chore'
version-resolver:
major:
labels:
- 'major'
minor:
labels:
- 'minor'
patch:
labels:
- 'patch'
default: patch
template: |
## What’s Changed
$CHANGES
簡単にします。
name-templateはリリースノートのタイトルとなる部分で、tag-templateはリリースタグとして用いられる値を指定するものになっています。
$RESOLVED_VERSIONを指定しておくと version-resolver
で記載したルールに基づきGitHub labelに基づいたバージョニングを自動で行ってくれます。
今回の設定ではdefault設定としてpatchを指定しているので、最新のDraftリリースノートが生成される際にはセマンティックバージョンに則って、patchバージョンがインクリメントされる形となります。
自動生成されたリリースノートはこのような形になります。
また、categoriesの指定をしておくと、各対応に付与されたlabelに基づいてマークダウンファイルをセクション分けして表示することも可能です。必要に応じて設定しておくと良いでしょう。
他にも細かいユースケースをカバーする機能がいくつも提供されているので、利用の際には一度READMEを確認しておくことをお勧めします。
実装は上記の対応だけで完了しました。
リリースノートのPublish
設定が完了すると、あとはdevelopにPRがマージされるたびに自動でリリースノートが更新されていきます。このフローによって生成されたリリースノートはDraftの状態で止まっているので、開発フロー内の最適なタイミングでPublishを行います。
下記の画像はDraft状態のリリースノート編集画面です。tagやTarget, 本文やタイトルなどを改めて確認し、必要に応じてここで修正や微調整をします。
あとは Publish release
をクリックするだけで簡単にリリースノートの作成ができました。
おわりに
このようにrelease-drafterをGitHub Actionsに組み込むことで、簡単に以下を実現することができました。
- 手作業による開発案件リストアップ作業 の排除
- 対応の抜け漏れ防止
- ドキュメント管理コストの削減
- その時点でのdevelopに何がマージされているかを可視化
- 各対応とPRの紐付け自動化
この対応で、より本質的な開発作業に集中することができそうです👍
Discussion