デプロイ 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-publicapi/wrangler.public.tomlmobile (/v1/public/*)
parky-api-adminapi/wrangler.admin.tomladmin portal
parky-api-marketingapi/wrangler.marketing.tomlmarketing portal
parky-api-store-syncapi/wrangler.store-sync.tomlstore-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 ベースで戻す場合

  1. git revert <bad-sha> → push
  2. main へマージで deploy-api-{public,admin,marketing,store-sync}-prod.yml のうち 関連 worker の workflow が走って前バージョンに戻る
  3. 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 操作:

  1. https://dash.cloudflare.com/ → Pages → 対象プロジェクト
  2. Deployments タブで戻したい成功デプロイを選択
  3. 「Rollback to this deployment」

git ベースで戻す場合

  1. git revert <bad-sha> → push
  2. 対応する 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 を戻す手順:

  1. dev DB を直接 ALTER で巻き戻し (ALTER TABLE ... DROP COLUMN IF EXISTS 等、べき等で書く)
  2. bash scripts/db/refresh-baseline.shinfra/supabase/baseline/ を再生成
  3. git diff infra/supabase/baseline でレビュー → アプリ側コード戻しと 同じ PR で commit
  4. 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 は不要との判断もあり)
↗ Source markdown (deployment-rollback.md)