アプリ リリース
Flutter アプリのリリースを行う。 タグ push 後は GH Actions が自動でビルド・署名・配布・GitHub Release を作成する。
前提
- main ブランチで作業中であること
- 未コミットの変更がないこと
指定済みのバージョン・対象を優先する。未指定の項目は以下の既定ルールで決定し、決定内容と理由を報告してリリースを進める。リリース依頼に含まれるコミット・push・タグ作成に追加の承認を求めない。
手順
1. 現在のバージョン確認 & 変更内容の収集
bashgrep '^version:' apps/mobile/pubspec.yaml
version: X.Y.Z+N の形式。+N は build number。
前回リリースからの差分を確認する:
bash# 前回のタグ（iOS/Android/macOS/Linux/Windows のいずれか新しい方） git tag -l 'ios/v*' 'android/v*' 'macos/v*' 'linux/v*' 'windows/v*' --sort=-v:refname | head -1 # 差分コミット（bridge 以外） git log $(git tag -l 'ios/v*' 'android/v*' 'macos/v*' 'linux/v*' 'windows/v*' --sort=-v:refname | head -1)..HEAD --oneline -- apps/mobile/ CHANGELOG.md
2. バージョンとプラットフォームを決定
差分コミットと実装内容から、次の優先順で決定する。指定済みのバージョンは再確認しない。
- 破壊的変更（
!、BREAKING CHANGE、実際の互換性破壊）がある →major。未承認の場合だけ、具体的なバージョンと互換性への影響を示してユーザーに確認する。 - 破壊的変更がなく
feat/ 新機能がある →minorを自動採用する。 - その他の修正・改善・保守変更 →
patchを自動採用する。
build number は現在の値 +1 とする。
プラットフォーム指定がなければ iOS + Android + macOS + Linux + Windows 全部を対象にする。「モバイルのみ」は iOS + Android、「デスクトップのみ」は macOS + Linux + Windows とし、個別指定があればその対象だけを使う。
3. CHANGELOG 更新
CHANGELOG.md（ルート）の先頭に新しいセクションを追加する。
markdown## [X.Y.Z] - YYYY-MM-DD ### Added - ... ### Changed - ... ### Fixed - ...
ステップ 1 で確認したコミットを元に、Added / Changed / Fixed に分類する。 空のセクション（該当なし）は省略する。
4. バージョン bump
apps/mobile/pubspec.yaml の version をステップ 2 で決定したバージョンに更新する。
5. ローカル検証
タグpush前に、CDと同じチェックをcompactラッパーで実行する。 成功時は解析・テスト・合計時間の3行だけを返す。失敗時は一時ログのパスと 最大120行の末尾だけを返す。すべてpassしなければ次へ進まない。
bashbash scripts/release/run-checks.sh
失敗した場合は原因を調査し、今回の変更に起因する問題を修正・再検証する。既存の無関係な問題や権限・認証など自力で解消できない障害が残る場合は、失敗内容と必要な対応を報告し、タグをpushしない。
6. コミット & push
bashgit add apps/mobile/pubspec.yaml CHANGELOG.md git commit -m "chore: bump version to X.Y.Z+N" git push origin main
6.1. Windows preflight（Windowsを選択した場合）
Windowsタグを含むリリースでは、いずれのプラットフォームタグも作成する前に、
リリースコミットと同じSHAで起動した Test workflowの成功を確認する。
通常CIの mobile-windows jobが、リリースworkflowと同じFlutter全テストを
windows-2022 で実行する。
bashrelease_sha=$(git rev-parse HEAD) node scripts/release/monitor.mjs preflight --sha "$release_sha"
監視スクリプトは起動検出を10秒間隔、実行中を30秒間隔で確認し、状態変化と
3分ごとのheartbeatだけを出す。起動しなければ2分、完了しなければ15分で失敗する。
個々のgh呼び出しも60秒で打ち切り、最大3回まで再試行する。
失敗時はjob・step・run URLと、完全な失敗ログを保存した一時パスを1行で返す。
タグは作成せず、必要なログ箇所だけを調査して修正コミットをpushし、新しいSHAで
preflightをやり直す。タグがなければ同じversion/build numberを使用できる。
6.2. タグ
ローカル検証と、Windows選択時のpreflightがすべて成功した後で、 ステップ2で選択されたプラットフォームのタグを作成・pushする。 Windowsを含む複数プラットフォームのリリースでは、preflight成功前に他のタグも作成しない。
ステップ 2 で選択されたプラットフォームのタグを打つ:
各タグは必ず別々の git push で送信すること。 GitHubは4個以上のタグを
1回のpushで送るとtag pushイベントを生成しないため、複数タグを1つの
git push origin <tag> <tag> ... にまとめてはならない。
bash# iOS（選択された場合） git tag ios/vX.Y.Z+N git push origin ios/vX.Y.Z+N # Android（選択された場合） git tag android/vX.Y.Z+N git push origin android/vX.Y.Z+N # macOS（選択された場合） git tag macos/vX.Y.Z+N git push origin macos/vX.Y.Z+N # Linux（選択された場合） git tag linux/vX.Y.Z+N git push origin linux/vX.Y.Z+N # Windows（選択された場合） git tag windows/vX.Y.Z+N git push origin windows/vX.Y.Z+N
7. 完了確認
タグ push 後、GH Actions が自動実行される:
| タグ | ワークフロー | 内容 |
|---|---|---|
ios/v* | ios-release.yml | Shorebird release iOS → TestFlight → GitHub Release |
android/v* | android-release.yml | Shorebird release Android → Google Play (internal draft) → GitHub Release |
macos/v* | macos-release.yml | Developer ID 署名 → 公証 → DMG → GitHub Release |
linux/v* | linux-release.yml | Linux release build → Xvfb smoke → tar.gz → GitHub Release |
windows/v* | windows-release.yml | Windows release build → smoke → zip → GitHub Release |
タグをpushしたプラットフォームだけをカンマ区切りで指定する:
bashnode scripts/release/monitor.mjs release \ --version "X.Y.Z+N" \ --platforms "ios,android,macos,linux,windows"
監視スクリプトは全タグが同じcommitを指すことを検証し、exact tag/SHAのrunだけを
追跡する。起動検出は10秒間隔、開始後10分までは60秒間隔、その後は90秒間隔で確認し、
状態変化と3分heartbeatだけを出す。起動しなければ2分、完了しなければ40分で失敗する。
platformごとのworkflow名も照合し、同じtag/SHAで動く別workflowを成功扱いしない。
gh run watchや個別のgh run listを直接繰り返さない。
失敗時はcompactなjob/step要約と一時ログを調査する。全ログを会話へ貼らない。
全対象がcompleted/successになるまでリリースを完了扱いにしない。
