セルフホスト更新の安全設計――preflight・snapshot・apply・verify・rollback

コード、Worker Assets、D1 migrationが同時に変わる更新で、適用前検査と復旧材料をどこまで自動化しているか。

コードから観測できること

1. update-engineにはpreflight、snapshot、apply、verify、rollbackが独立phaseとして存在する。更新を単一のdeploy commandではなく、検証可能な状態遷移として扱っている。
2. Cloudflare Worker、Assets、Pages、D1用のAPI処理が別モジュールに分かれ、失敗対象を特定できる。rollback可能性は対象リソースごとに異なる。
3. D1 migrationの破壊的変更はコードversionを戻すだけでは元に戻らない場合がある。『Worker rollback成功』と『データ完全復旧』は別の結果として報告する。

再現・追加測定の手順

1. 更新前versionとschemaをsnapshotする
2. 各phase直後に意図的な失敗を起こす
3. rollback後のWorker・Assets・schemaを比較する
4. 再度同じ更新を実行し冪等性を確認する

この資料だけでは証明できないこと

1. 外部APIや利用者が更新中に書き込んだデータはsnapshot境界外になる可能性がある。
2. rollbackテストは本番データの代替にならず、バックアップ方針が別途必要。

このページは新しいcommit、実測ログ、API仕様変更が得られた時点で更新します。古い観測条件と現在仕様を混同しないため、固定commitへのリンクを残します。