#9 Release Drafterでリリースノート自動生成 - Python OSS開発記録
karrinn
著者
リリースのたびに「v0.1.0で何変えたっけ？」とPRを漁るの、めちゃくちゃ面倒じゃないですか？
Release Drafterを使えば、PRラベルから自動でリリースノートを生成してくれます。今回はwagtail-reusable-blocksでの設定を振り返ります。
KEY TAKEAWAYS
この記事でわかること
- Release Drafterの仕組みと自動化できること
- release-drafter.ymlの設定（categories・autolabeler・version-resolver）
- 実際のリリースノート生成フロー
用語の定義
TERM 01
Release Drafter
GitHub ActionsでリリースノートとRelease Draftを自動生成するツール。PRのラベルやタイトルから変更履歴をまとめ、セマンティックバージョニングも自動推定します。
TERM 02
Release Draft
GitHubのReleases機能で作成される下書きです。公開前にリリースノートを確認・編集でき、公開ボタンを押すまで外部には見えません。
TERM 03
Autolabeler
PRのブランチ名・変更ファイルから自動的にラベルを付与する機能です。feature/xxxブランチなら「enhancement」、fix/xxxなら「bug」などを自動判定します。
TERM 04
セマンティックバージョニング
バージョン番号の付け方の規約（major.minor.patch）です。破壊的変更はmajor、新機能はminor、バグ修正はpatchを上げます。Release Drafterが自動推定できます。
Source: Semantic Versioning 2.0.0
Release Drafterとは何か
Release Drafterは、PRがマージされるたびに、自動でRelease Draftを更新してくれるGitHub Actionsです。
何を自動化してくれるのか
1. 変更履歴の収集
マージされたPRのタイトル・ラベルを自動収集します。
「v0.1.0で何変わったっけ？」を手動で調べなくて済みます。
2. カテゴリ分類
PRのラベルから「Features」「Bug Fixes」などに自動分類します。
見やすいリリースノートに整形してくれます。
3. バージョン番号の推定
ラベルからmajor/minor/patchを自動判定します。
「次は0.2.0？0.1.1？」と迷う必要がなくなります。
4. Release Draftの作成
GitHubのReleasesページに下書きを作成します。
最終確認してPublishするだけでリリース完了です。
つまり: リリース時に「PRを漁ってコピペして...」という手作業が完全になくなります。
Source: Release Drafter - GitHub
手動でリリースノートを作る問題
Release Drafterを使わないと、リリースのたびにこんな作業が発生します。
よくある手動リリースの悲劇
- 前回のタグから今回までのPRを全部確認
GitHubのPRリストをスクロールして、「あれ、v0.0.9の次はどこだっけ？」 - PRタイトルをコピペしてカテゴリ分け
「これはFeature、これはBug Fix...」と手動で分類。めちゃくちゃ面倒です。 - バージョン番号を考える
「新機能あったからminor上げて...0.1.0かな？」と毎回悩みます。 - リリースノートをMarkdownで書く
フォーマットを整えて、リンクを貼って...時間がかかります。 - 見落としや誤字のリスク
「あ、このPR書き忘れた！」「typoってた！」→ 公開後に修正は恥ずかしいですよね。
リリースのたびに30分〜1時間かかる
Release Drafterを使えば、この作業が完全自動化されます。
リリース時にやることは、「Release Draftを確認してPublishボタンを押す」だけです。
実装: Release Drafterの設定
wagtail-reusable-blocksでの実際の設定を見ていきましょう。2つのファイルが必要です。
ファイル1: GitHub Actions workflow
場所:.github/workflows/release-drafter.yml
これがいつRelease Drafterを実行するかを定義します。
この設定のポイント
push: mainへのpush時に実行pull_request_target: PRのopen/reopen/更新時にAutolabelerが動作permissions: Release作成とPRラベル付けに必要な権限config-name: 次に説明する設定ファイルを指定
name: Release Drafter
on:
push:
branches:
- main
pull_request_target:
types: [opened, reopened, synchronize]
permissions:
contents: write
pull-requests: write
jobs:
update_release_draft:
runs-on: ubuntu-latest
steps:
- uses: release-drafter/release-drafter@v6
with:
config-name: release-drafter.yml
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}ファイル2: Release Drafter config
場所:.github/release-drafter.yml
これがどうリリースノートを生成するかの詳細設定です。wagtail-reusable-blocksの実際の設定を見ていきましょう。
セクション1: バージョン設定
リリース名とタグ名を「v0.1.0」形式で自動生成します。$RESOLVED_VERSIONは後述のversion-resolverで決定されます。
name-template: "v$RESOLVED_VERSION" tag-template: "v$RESOLVED_VERSION"
セクション2: カテゴリ分類
PRのラベルから変更をカテゴリ分類します。
「enhancement」ラベルのPRは「Features」セクションに、「bug」ラベルは「Bug Fixes」に自動振り分けされます。
categories: - title: "Features" labels: - "enhancement" - "implementation" - title: "Bug Fixes" labels: - "bug" - title: "Documentation" labels: - "documentation" - "documentation-org" - title: "Maintenance" labels: - "cleanup" - "organization" - "automation"
セクション3: 除外ラベル
「skip-changelog」ラベルのPRはリリースノートから除外されます。内部的なリファクタリングなどに便利です。
exclude-labels: - "skip-changelog"
セクション4: 変更項目のフォーマット
各PRを「- Add ReusableBlock model @kkm-horikawa (#11)」形式で表示します。
Markdown特殊文字はエスケープされます。
change-template: "- $TITLE @$AUTHOR (#$NUMBER)" change-title-escapes: '\<*_&'
セクション5: バージョン番号の自動推定
ルール:
- 「priority:critical」ラベル → major（1.0.0 → 2.0.0）
- 「enhancement」「implementation」 → minor（0.1.0 → 0.2.0）
- 「bug」「documentation」など → patch（0.1.0 → 0.1.1）
- どれもない場合 → patch（デフォルト）
version-resolver: major: labels: - "priority:critical" minor: labels: - "enhancement" - "implementation" patch: labels: - "bug" - "documentation" - "cleanup" - "organization" default: patch
セクション6: Autolabeler（自動ラベル付け）
自動ラベル付けルール:
feature/xxxブランチ → 「enhancement」ラベル自動付与fix/xxxブランチ → 「bug」ラベル自動付与*.mdファイル変更 → 「documentation」ラベル自動付与- → 手動でラベル付けしなくてもいい
autolabeler: - label: "documentation" files: - "*.md" - "docs/**/*" branch: - "/docs\\/.+/" - label: "bug" branch: - "/fix\\/.+/" - "/bugfix\\/.+/" - label: "enhancement" branch: - "/feat\\/.+/" - "/feature\\/.+/" - label: "automation" branch: - "/chore\\/.+/"
セクション7: リリースノートのテンプレート
$CHANGESにカテゴリ分類された変更リストが挿入されます。
フッターには前回タグとの比較リンクを自動生成します。
template: | ## What's Changed $CHANGES footer: | **Full Changelog**: https://github.com/$OWNER/$REPOSITORY/compare/$PREVIOUS_TAG...v$RESOLVED_VERSION
Source: Release Drafter README.md
実際の動作フロー
Release Drafterが実際にどう動くか、具体例で見ていきましょう。
動作の流れ
- PR作成:
feature/11-reusable-block-model
→ Autolabelerが「enhancement」ラベルを自動付与 - PRマージ → mainブランチにpush
→ Release Drafter workflowがトリガー - Release Drafterが実行
・PRのラベル「enhancement」を確認
・version-resolverで「minor」と判定
・次のバージョンを「v0.1.0」と推定
・「Features」カテゴリに追加 - Release Draftが更新される
GitHubのReleasesページで下書きを確認できます - リリース時: Publishボタンをクリック
→ リリースノートが公開されます
生成されるリリースノートの例
カテゴリごとに整理され、PRへのリンク付きです。
最後にFull Changelogリンクも自動生成されます。
## What's Changed Features - Add ReusableBlock model @kkm-horikawa (#11) - Implement slot system @kkm-horikawa (#15) Bug Fixes - Fix circular reference detection @kkm-horikawa (#12) Documentation - Update README with installation guide @kkm-horikawa (#14) **Full Changelog**: https://github.com/kkm-horikawa/wagtail-reusable-blocks/compare/v0.0.1...v0.1.0
トピック#4・#6との相乗効果: 完全自動化のチェーン
Release Drafterの真価は、ブランチ命名規則の強制（トピック#6）と組み合わせた時に発揮されます。
3つのトピックが連携する仕組み
1. Git Flow
トピック#4
ブランチ命名規則を決定feature/xxxfix/xxxchore/xxxdocs/xxx
2. Rulesets
トピック#6
ブランチ命名を強制
規則外のブランチ名は作れない
→ 100%規則通りのブランチ名
3. Release Drafter
トピック#9
ブランチ名から自動ラベル
→ 自動カテゴリ分類
→ 自動バージョン推定
→ リリースノート自動生成
完全自動化のチェーン
この3つが連携すると、開発者は何も考えずにブランチを切ってPRを出すだけ。
リリースノートは勝手に生成され、バージョン番号も勝手に決まります。人間の手作業ゼロです。
実際の自動化フロー
新機能開発の例
- 開発者:
feature/11-reusable-block-modelブランチ作成
→ Rulesetsが「feature/」を確認、OK - 開発者: PRを作成
→ Release Drafter autolabelerが実行
→ ブランチ名「feature/」を検知
→ 「enhancement」ラベルを自動付与 - PRマージ → mainへpush
→ Release Drafterが実行
→ 「enhancement」ラベルを確認
→ version-resolverで「minor」と判定
→ 「Features」カテゴリに追加
→ 次のバージョンを「v0.1.0」と推定 - リリース時: Publishボタンをクリック
→ リリースノート完成、v0.1.0として公開
開発者がやったこと
git checkout -b feature/11-reusable-block-model- コード書く
- PR作成
- 以上！
自動で行われたこと
- ブランチ名の検証（Rulesets）
- ラベル付与（Autolabeler）
- カテゴリ分類（Release Drafter）
- バージョン番号推定（Version resolver）
- リリースノート生成（Release Drafter）
Rulesetsがないと何が起きるか
もしトピック#6のRulesetsでブランチ命名を強制していないと、こうなります：
悪い例: ブランチ名がバラバラ
add-reusable-block← プレフィックスなしfeat/reusable-block← featはGit Flowにないreusable-block-feature← ルール無視makoto/reusable-block← 個人名
結果:
- Autolabelerが機能しない
- 手動でラベル付け必要
- ラベル付け忘れ発生
- リリースノートが不正確
Rulesetsで強制 = Autolabelerが100%機能
トピック#6でブランチ命名を技術的に強制すれば、全てのブランチが規則通り。
→ Autolabelerが100%正確に動作する。
→ リリースノートも100%正確。
→ 人間の記憶や注意に頼らない
OSS vs 企業プロジェクト: Release Drafterの価値
OSS: ユーザーへの透明性とメンテナンスコスト削減
OSSプロジェクトでは、リリースノートがユーザーとのコミュニケーション手段です。
「v0.2.0で何が変わったの？」をすぐに伝える必要があります。
Release Drafterのメリット
- 透明性: 全ての変更が自動的にリリースノートに記録される
- 一貫性: フォーマットが統一され、見やすい
- 時間節約: リリースのたびに手作業でまとめる必要がない
- 見落とし防止: マージされたPRは全て自動収集される
ユーザーに優しい: リリースノートが充実していると、「このプロジェクト、ちゃんとメンテされてるな」という信頼感につながります。
企業: リリース作業の標準化と属人化の排除
企業プロジェクトでは、「リリース担当者がいないとリリースできない」という状況が起きがちです。
よくある問題
- リリース担当者が休むとリリースできない → 属人化
- リリースノート作成に時間がかかる → 「今日はリリース無理」
- 人によってフォーマットが違う → 一貫性がない
- 変更の見落とし → 「あの修正、リリースノートに書き忘れた！」
Release Drafterによる解決
Release Drafterを導入すれば、誰でもリリースできるようになります。
- リリースノートは自動生成 → 担当者の知識不要
- フォーマット統一 → 誰がやっても同じ品質
- 見落としゼロ → システムが全PRを収集
- バージョン番号も自動推定 → 「次は0.2.0？0.1.1？」と悩まない
システムで標準化:リリース作業を誰でもできるようにすることで、属人化を防ぎ、休暇も取りやすくなります。
これは心理的安全性にもつながります。
実例: 手動デプロイ + Excel管理の問題
過去に関わったDjangoプロジェクトで、リリース作業に丸一日かかるという現場がありました。
Excelリリースノート管理の問題点
- 書き方のルールが人によってブレる
→ Aさんは詳細に書く、Bさんは簡潔、Cさんは技術用語満載... - リンクを貼るのが大変
→ PR番号を手動でコピペ、URLを手動で作成... - リンク先が人によってバラバラ
→ Aさんはコミットリンク、Bさんはプルリクエストリンク、CさんはRedmineチケットリンク...
→ Backlogに移行したら、ある時点より前のリンクが全てリンク切れ
→ 過去のリリースノートが使い物にならない - 見落としが発生
→ 「あのPR、リリースノートに書き忘れた！」
本来、システムで担保すべきこと
| 時点 | システムで担保すべきこと | 手動だとどうなるか |
|---|---|---|
| コード変更時 |
・ブランチ命名規則の強制（Rulesets） ・自動テスト実行（CI） ・自動ラベル付け（Autolabeler） |
「ブランチ名はfeature/で」と口頭指示 → 忘れる、守らない |
| PR作成時 |
・必須レビュアー設定（CODEOWNERS） ・CIチェック必須（Rulesets） ・リリースノート自動収集（Release Drafter） |
「誰かレビューして」と依頼 → 見落とし、スキップ |
| リリース時 |
・タグによるバージョン管理 ・自動デプロイ（GitHub Actions） ・自動ロールバック機能 |
手動コマンド実行 → タイポ、手順ミス、ロールバック失敗 |
きちっとシステムで整備すれば、こういうことは起きない
どの時点で何が担保されているかをルール・システム上で明確にしておけば：
・ブランチ命名ミス → システムが弾く
・レビュー漏れ → システムが弾く
・mainへの直push → システムが弾く
・デプロイミス → 自動化されているので起きない
→ 「今日は失敗でした、また明日やります」が起きない
Release Drafter導入後: リリース作業が15分に
何が変わったか
- リリースノートは自動生成済み → Release Draftを確認するだけ
- フォーマット統一 → 誰が書いても同じ品質
- リンクも自動 → PR番号から自動でURL生成
- 見落としゼロ → マージされたPRは全て収集
- Excelとお別れ → GitHubのReleasesで管理
リリース作業の流れ（導入後）
- GitHubのReleasesページを開く（1分）
- Release Draftを確認（5分）
- 必要なら微修正（5分）
- Publishボタンをクリック（1分）
- GitHub Actionsが自動デプロイ（3分）
合計: 約15分 （従来: 1日 = 8時間 = 480分）
よくある質問
A: はい、完全無料です。
Release DrafterはGitHub Actionsで動作するため、GitHub Actionsの無料枠内で使えます。
Publicリポジトリなら無制限、Privateリポジトリでも月2,000分の無料枠があります（トピック#1参照）。
A: はい、Publish前なら自由に編集できます。
Release Drafterが生成した内容は下書きです。
GitHubのReleasesページで編集して、最終確認してからPublishしてください。
「この表現もっと詳しく書きたい」などの調整は自由にできます。
A: PRで手動でラベルを変更できます。
Autolabelerはあくまで自動付与なので、間違っていたら手動で修正してください。
PRマージ時のラベルが最終的にRelease Draftに反映されます。
A: はい、自動でまとめられます。
Release DrafterはPublishするまで下書きに追加し続けます。
例: PR #11, #12, #13をマージ → Release Draftに全て追加される → Publishで一度にリリース。
A: Release Draft編集時に変更できます。
Release Drafterの推定が「v0.1.1」でも、Publish前にタグ名を「v0.2.0」に変更できます。
version-resolverは推定値なので、最終判断は人間がします。
A: はい、workflowのbranchesを変更すれば可能です。
wagtail-reusable-blocksではmainブランチのみで動作するように設定していますが、developでも動かせます。
on: push: branches: - main - develop # 追加
ただし、リリースはmainブランチから行うので、wagtail-reusable-blocksではmainのみにしています。
まだコメントはありません。最初のコメントを残しませんか？