デプロイ Rollback 手順
SSoT 参照: 即時 rollback (= incident 中の高速復旧) は rollback-runbook.html を参照。 通知 channel / severity 振り分けは notification-strategy.html を参照。 Canary を中断して戻す場合は canary-deploy.html §2.3。
本 runbook は 平常時の通常 rollback コマンド集 (緊急 incident 用ではない) のみ扱う。
各デプロイ対象ごとの切り戻し方法。Parky の API は 4 worker split (api-public / api-admin / api-marketing / api-store-sync) で動作するため、対象 worker を明示する必要がある。
Cloudflare Workers (api/)
Worker 構成 (2026-04-30 split 後)
Worker name (name=) | wrangler config | 担当 channel |
|---|---|---|
parky-api-public | api/wrangler.public.toml | mobile (/v1/public/*) |
parky-api-admin | api/wrangler.admin.toml | admin portal |
parky-api-marketing | api/wrangler.marketing.toml | marketing portal |
parky-api-store-sync | api/wrangler.store-sync.toml | store-sync cron / queue |
parky-api (LEGACY) | api/wrangler.toml | 旧 monolith (DEPRECATED) |
wrangler.toml(旧 monolith) はdeploy-api-prod.ymlと一緒に LEGACY DEPRECATED マーク済。 通常作業対象は split 4 worker のみ。
直前バージョンへロールバック
cd parky/api
# 対象 worker を選択 (例: api-public dev)
npx wrangler rollback --config wrangler.public.toml --env dev
npx wrangler rollback --config wrangler.public.toml --env prod
# admin / marketing / store-sync も同様
npx wrangler rollback --config wrangler.admin.toml --env prod
npx wrangler rollback --config wrangler.marketing.toml --env prod
npx wrangler rollback --config wrangler.store-sync.toml --env prod
wrangler deployments list --config <wrangler-X.toml> --env <env> で履歴を確認できる。
緊急時 (incident 中) は scripts/deploy/rollback.sh api <env> がラッパーになっており、Discord #p0-alerts への START / DONE / FAILED 通知 + canary 中断まで自動化している。詳細は rollback-runbook.html §3。
git ベースで戻す場合
git revert <bad-sha>→ push- main へマージで
deploy-api-{public,admin,marketing,store-sync}-prod.ymlのうち 関連 worker の workflow が走って前バージョンに戻る - revert PR にも GitHub Environment (
production) の approval が要る
Cloudflare Pages (web/home, web/portal/admin, web/portal/owner, web/portal/marketing, mobileapp/prototype/web)
CLI からの rollback はサポートされていない。Dashboard 操作:
- https://dash.cloudflare.com/ → Pages → 対象プロジェクト
- Deployments タブで戻したい成功デプロイを選択
- 「Rollback to this deployment」
git ベースで戻す場合
git revert <bad-sha>→ push- 対応する
deploy-*.ymlが走って Pages を上書き
Supabase スキーマのロールバック (snapshot 戦略)
Parky は migration ファイルを持たず、infra/supabase/baseline/ (schema/table 単位 split) が dev DB スナップショットの SSoT。詳細は parky/CLAUDE.md §DB スキーマ変更フロー (snapshot 戦略 / 2026-04-29 採用)。
snapshot 戦略下で「migration revert」は存在しない。drift を戻す手順:
- dev DB を直接 ALTER で巻き戻し (
ALTER TABLE ... DROP COLUMN IF EXISTS等、べき等で書く) bash scripts/db/refresh-baseline.shでinfra/supabase/baseline/を再生成git diff infra/supabase/baselineでレビュー → アプリ側コード戻しと 同じ PR で commit- CI (
baseline-drift.yml/api-rls-tests/api-row-schema-drift) が green であることを確認
DROP COLUMN は本番側でも実施できるが、データ消失を伴う。 通常は forward fix (新カラム追加 → 旧カラムを ignore に変更 → 後日 drop) を優先する。 本番 DB を直接触る変更は
parky/CLAUDE.md§自律実行・自動化 のロールバック可能性条件を満たすこと。
supabase db reset は dev でのみ使用可。本番では絶対に実行しない。
関連 docs
- rollback-runbook.html — 緊急 incident 中の rollback (Sentry/healthz baseline×3 /
scripts/deploy/rollback.sh) - canary-deploy.html — canary 走行中の自動 / 手動 rollback
- split-worker-deploy-runbook.html — 4 worker split deploy の前提
.github/workflows/auto-rollback-prod.yml/auto-rollback-dev.yml— Sentry burst 検知 → 自動 rollback workflow
TODO
- 各 env の最新デプロイ sha を記録する仕組み (現状は
wrangler deployments list手動確認) - blue/green 化検討 (canary が安定したら blue/green は不要との判断もあり)