コンテンツにスキップ

リリース手順（develop → main）

本番へ出す唯一の経路です。CONTRIBUTING.md からここへ委譲しています。

⚠️ --head develop で直接 release PR を作らないこと。 main への過去のリリースはすべて squash マージなので main は develop の祖先になりません。 そのまま PR を作ると古い merge base が使われて数十ファイルが衝突し mergeable=CONFLICTING になります。このとき pull_request トリガのワークフローが 1 つも走りません （prod-critical-gate を含む）。v1.39.0 で実際に踏みました。 チェック一覧に prod-critical-gate が現れないのは異常シグナルです。

1. リリース前の確認

  • [ ] develop が緑（ci / security / rls-proofs / migration-proofs-docker）
  • [ ] 未リリース分に migration が含まれるかを確認する（git diff --name-only origin/main...origin/develop -- supabase/）
  • 含まれる場合: 番号が飛んでいないか（prod は厳格順序。番号の大きいものを先に出すと後続が落ちる）
  • データ移行を伴う場合: NOTICE の出方と件数の見込みを PR 本文に書く
  • [ ] pnpm verify 相当を候補コミットで通す（install / lint / arch / typecheck / test / build / semgrep / gitleaks）
  • [ ] docker proof を全流しする（scripts/proofs/*.sql 全部・[NG]=0・psql の exit code も見る）

1.1 S2 手動 dispatch（リリース前）

  • [ ] develop の実 dev で admin1 / staff1 / driver01 を使い、配車ボードを開く。
  • [ ] 当日の通常回収または二次搬出を1便だけ、担当・車両・完了時刻を確認して手動 dispatch する。
  • [ ] マニフェスト証跡、目方、運行日報、請求プレビューまでの golden path を確認する。
  • [ ] E2E 予約 actor、取引先 000100、保存・取消以外のデータ変更を使わない。

2. リリースブランチを切る（content-neutral 取込）

git checkout -B release/vX.Y.Z origin/develop
git merge -s ours origin/main          # main の履歴だけ取り込み、ツリーは develop のまま
git diff --stat origin/develop HEAD    # ← 差分 0 行であることを必ず確認
git push -u origin release/vX.Y.Z

-s ours は「main 側の変更を採用しない」マージなので、ツリーは develop と完全に同一に なります（差分 0 行の確認がその証明）。これで merge base が最新になり、pull_request ワークフローが正しく走ります。

3. PR を作る

gh pr create --base main --head release/vX.Y.Z --title "release: vX.Y.Z — <要約>"

PR 本文に入れるもの:

  • 収載 PR の一覧（番号 + 一行要約）
  • migration の有無（無い場合は「migration なし」と明記する。あると誤解されると本番確認の 手順が変わる）
  • 検証結果の表（verify ゲート・docker proof・ミューテーションの有無）
  • デプロイ後に確認すること（画面・ワークフローの成否）

4. 人間ゲート（human-reviewed ラベル）

prod-critical-paths.txt に載るファイル（migration / auth / billing / signup / team / OCR ルート（apps/api/src/routes/jwnet.ts を含む）/ JWNET 認可（apps/api/src/jwnet/authz.ts）/ 生成 DB 型 / 共有スキーマ / wrangler / workflows / env 系）に触れた main 向け PR は、human-reviewed ラベルが付くまで prod-critical-gate が赤のままです。

  • ラベル付与は人間の UI 操作に限ります（エージェントは付けません）。
  • develop 等への PR はラベル不要です（人間レビューは main マージ時のみ）。
  • main にブランチ保護は未設定なので、このゲートは機械的強制ではなく運用規約です。 したがって git push origin main の直接プッシュと workflow_dispatch の手動実行は禁忌です。

5. マージとタグ

gh pr merge <PR番号> --squash            # main は 1 リリース = 1 コミット
git fetch origin main
git tag -a vX.Y.Z <main のマージ commit> -m "vX.Y.Z — <要約>"
git push origin vX.Y.Z

タグは注釈タグ（-a）にして、本文に主要変更を箇条書きします。タグ自体はワークフローを トリガーしません。

6. デプロイの確認

ワークフロー いつ動くか 見るもの
Cloudflare Pages main への push success（web の本番反映）
Deploy API (Workers) apps/api/** or packages/shared/** の変更時 success
Supabase Deploy supabase/migrations/** の変更時 success + migration の適用順序と NOTICE 件数
  • migration が無いリリースでは Supabase Deploy は動きません（正常）。
  • migration があるリリースでは、適用順序（番号順になっているか）とデータ移行 NOTICE の件数を ログで確認します。

7. 後片付け

git push origin --delete release/vX.Y.Z

8. リリース後

  • beads の該当イシューを bd close し、Notion（🗺 ロードマップ / 📋 週次レポート）へリリース番号を記録する
  • 本番で最低限の目視（このリリースで変えた画面が開くか）