4Hえんぴつ｜React＋TypeScriptでWeb RPGを作る
第8章「Web公開・互換性・永続化」
第44回：初回リリースでも戻れるようにする――rollback anchorの設計
1. 今回のテーマ
前回は、
Same Candidate
↓
Local Hosting
↓
E2E
Same Candidate
↓
Production Hosting
↓
E2E
という形で、localhostだけで終わらせず、実際のproduction URLまで確認する方法を扱いました。
今回は、その次です。
productionへ出したあと、
もし問題が見つかったら、どこへ戻るのか
を考えます。
通常のrollbackなら、
現在のproduction
↓
一つ前の正常deploy
へ戻せます。
しかし今回の正式公開は、
初回リリース
でした。
つまり、
戻るべき「一つ前の正常production」が存在しない
という問題がありました。
2. rollbackは「前の版へ戻す」だけではない
rollbackというと、
v1.6.0
↓
問題発生
↓
v1.5.0へ戻す
というイメージがあります。
しかし、初回公開では、
v1.5.0
のような、過去の成功production deployがありません。
そのため、
問題が起きたら前へ戻す
という通常の手順そのものが成立しません。
3. 初回リリース特有の問題
今回の状況を整理すると、
正式候補
↓
v1.6.0
過去の成功production
↓
なし
でした。
この状態で、
そのままproductionへ切り替えると、
もし公開後に、
直URLが壊れていた
IndexedDB保持に問題があった
productionだけで例外が出た
といった問題が見つかった場合、
すぐ戻せる正常地点がない
ことになります。
4. そこでrollback anchorを作る
今回採用したのが、
rollback anchor
という考え方です。
正式候補そのものから、
あらかじめ、
戻れることを確認済みのdeploy
を作っておきます。
今回の方式では、
INITIAL_RELEASE_ANCHOR
という位置づけにしました。
5. anchorは別のコードではない
ここで重要なのは、
rollback anchor用に、
別のコードを作らないことです。
例えば、
正式候補
↓
v1.6.0
anchor用
↓
少し修正した別版
では意味がありません。
戻った先が、
正式候補とは違うものになってしまいます。
6. exact frozen candidateから作る
そこで、
anchorは、
exact frozen candidate
から作ります。
つまり、
正式候補
↓
内容を凍結
↓
そのexact candidateからanchor生成
です。
正式公開資料でも、anchor生成元は、
exact frozen candidate v1.6.0
と記録されています。
7. 「exact」であることが大切
例えば、
candidate確認後に、
ちょっとだけ文言修正
してからanchorを作ると、
candidateとanchorが別物になります。
すると、
どちらを正式に確認したのか
が曖昧になります。
そのため、
同じcandidate
同じ成果物
同じ内容
であることを重視します。
8. anchorを作っただけでは足りない
rollback anchorを作っても、
そのdeployが正常に動く保証はありません。
そこで、
anchor自身に対して、
hosting確認を行います。
今回の正式受入では、
Anchor hosting
G06-H01～H07
7 / 7 PASS
まで確認しています。
9. anchor固有URLで先に確認する
いきなりproductionへ切り替えるのではなく、
まず、
anchor固有URL
で確認します。
つまり、
anchor生成
↓
anchor固有URL
↓
E2E / hosting確認
↓
正常
です。
これにより、
productionを触る前に、
戻り先として使えることを確認できます。
10. 戻り先を先に検証する
通常は、
問題が起きた
↓
戻る
↓
戻った先を確認
になりがちです。
しかし、今回の考え方は逆です。
戻る先を先に作る
↓
戻る先を先に確認する
↓
そのあとproductionを切り替える
です。
これがrollback anchorの一番重要なところです。
11. 一時的にproductionへPublishする
anchorが正常だと確認できたら、
一時的に、
anchor
↓
production
へ切り替えます。
これで、
実際にproductionとして公開可能か
も確認できます。
正式受入では、
Anchor一時Publish：PASS
となっています。
12. production URLでfresh session smokeを行う
productionを切り替えたら、
既存ブラウザ状態に依存しないよう、
fresh sessionでも確認します。
例えば、
新しいブラウザ状態
↓
primary production URLへアクセス
↓
正常起動
です。
今回の正式受入でも、
fresh session smoke：PASS
を確認しています。
13. なぜfresh sessionなのか
既存セッションでは、
既存IndexedDB
cache
既存ルート状態
などが残っている可能性があります。
それらがあると、
本当はproductionに問題があるのに、
以前の状態で動いているように見えることがあります。
そのため、
何も持っていない状態
↓
productionを開く
確認を入れます。
14. rollback確認中は状態変更操作をしない
今回のrollback確認では、
状態変更操作を行わない
ことも条件にしています。
正式資料でも、
状態変更操作：なし
と記録されています。
なぜなら、
rollback確認の目的は、
production切替
↓
戻せるか
を見ることだからです。
15. 確認中に余計な状態を作らない
例えば、
rollback確認中に、
新しいセーブ作成
上書き
進行状態変更
を行うと、
前後の状態比較が複雑になります。
今回はブラウザローカル保存なので、
サーバー側共有データを変更するわけではありません。
それでも、
確認目的を明確にするため、
rollback試験中は必要以上に状態を変えない
方針にしました。
16. anchorへ切り替えたあと、元の正式deployへ戻す
今回確認したかったのは、
anchorをproductionにできることだけではありません。
その後、
anchor production
↓
元の正式deploy
へ戻せることも確認します。
正式資料では、
復元先deploy IDとして、
6a8892cb0ccf1b235b1c7c1e
が記録されています。
17. 「戻した」だけでは完了にしない
productionを元のdeployへ戻したあとも、
そこで終わりではありません。
再び、
hosting確認を行います。
正式受入では、
復元後hosting
7 / 7 PASS
を確認しています。
18. rollbackの成功条件は「元に戻った」まで
つまり、rollback確認は、
切り替えられた
だけでは足りません。
今回の成功条件は、
anchorを確認
↓
productionへ切り替え
↓
fresh session確認
↓
元deployへ戻す
↓
復元後も7 / 7 PASS
です。
ここまでで、
戻せることを実証した
と考えます。
19. rollback手順もテスト対象になる
通常、rollbackは、
障害時に使う運用手順
として、
実際に障害が起きるまで試さないこともあります。
しかし、それでは、
本当に戻れるか分かりません。
そこで、
公開前に、
rollback手順そのものを試験する
ようにしました。
20. 「戻せるはず」をなくす
例えば、
Netlifyなら過去deployへ戻せるはず
と考えるだけでは、
初回リリース時のように、
そもそも戻る先がない
問題を見落とします。
実際に今回、
初回リリース特有の問題として、
過去の成功production deployが存在しないことが判明しました。
21. 問題が見つかったから設計を追加した
これは最初から完璧に決めていた手順ではありません。
正式公開へ向けて確認する中で、
通常rollback
↓
使えない
理由
↓
過去成功deployがない
ことが分かりました。
そこで、
INITIAL_RELEASE_ANCHOR
方式を追加しました。
22. 初回リリースと通常リリースではrollback条件が違う
2回目以降のリリースなら、
例えば、
v1.6.0
↓
現在の正常production
v1.7.0
↓
新candidate
という状態になります。
この場合は、
問題があれば、
v1.6.0
へ戻せる可能性があります。
しかし、初回ではそれがありません。
つまり、
リリース回数によってrollback設計も変わり得る
ということです。
23. anchorは初回リリース用の安全地点
今回のINITIAL_RELEASE_ANCHORは、
名前のとおり、
初回正式リリース向け
の考え方です。
通常の過去deploy rollbackを置き換える普遍的な方法ではありません。
必要な条件に合わせて、
今回の初回公開で使った仕組みです。
24. rollbackとbackupは似ている
ここまでの連載では、
セーブデータでも、
current
backup
quarantine
という設計を使ってきました。
考え方としては、
rollbackも少し似ています。
新しい状態へ進む
↓
問題があれば
↓
安全な以前の状態へ戻る
です。
対象が、
セーブデータなのか、
公開deployなのか、
という違いがあります。
25. 「変更前の安全地点」を作るという共通点
セーブでは、
current更新前
↓
backupを残す
でした。
公開では、
production切替前
↓
rollback anchorを用意する
です。
どちらも、
変更してから戻り先を考えるのではなく、変更する前に戻れる場所を作る
という考え方です。
26. fail-closedともつながる
この連載では、
future schemaや破損セーブでも、
安全か判断できない
↓
先へ進めない
というfail-closedを使ってきました。
リリースでも、
戻れるか確認できていない
↓
そのまま正式公開へ進む
のではなく、
戻れることを確認
↓
公開判定へ進む
方が安全です。
27. rollback anchorにも同じ品質ゲートを使う
anchorだから、
簡易確認だけでよい、
とはしません。
今回のanchorでも、
G06-H01～H07
7 / 7 PASS
を確認しています。
つまり、
戻り先にも、通常のhosting品質基準を適用する
ということです。
28. 戻り先の品質を下げない
例えば、
本番candidate
↓
厳格にテスト
rollback先
↓
起動だけ確認
では、
本当に戻したときに問題が出るかもしれません。
そのため、
rollback先にも、
同じ重要な確認を通します。
29. 最終productionが元deployへ戻ったことも確認する
切り替え操作が成功したように見えても、
本当に期待するdeployがproductionになっているか確認します。
正式資料では、
最終production
元の正式deployへ復元済み
と記録されています。
30. deploy IDを記録する意味
例えば、
画面が同じなら、
たぶん元に戻った
ように見えることがあります。
しかし、
deploy IDを記録しておけば、
どのdeployが
productionになっているか
を明確にできます。
リリース作業では、
画面だけでなく、
識別子も重要になります。
31. release candidateの固定ともつながる
第43回では、
localとproductionで、
同じcandidateを確認する
ことが重要だと書きました。
rollbackでも同じです。
exact candidate
↓
anchor
exact candidate
↓
正式release
の関係を崩さないようにします。
32. SHAやdeploy IDで追跡できるようにする
正式公開版では、
candidate ZIP、
package-lock、
正式release ZIP、
production deploy ID
などを記録しています。
これは、
何を確認し、何を公開し、どこへ戻したのか
を追えるようにするためです。
33. rollbackはリリース運用の一部
ここまで来ると、
rollbackは、
障害時の臨時対応ではなくなります。
Candidate
↓
Test
↓
Publish
↓
Verify
↓
Rollback capability
までを、
一つのリリース運用として考えます。
34. 公開前に「戻れる」を確認する
今回の正式公開では、
単に、
productionへ出せた
ことだけではありません。
productionへ出せる
戻せる
戻したあとも正常
までを受入条件に含めています。
35. 今回のポイント
今回のポイントは3つです。
- 初回リリースでは過去の正常production deployがないため、通常rollbackが成立しない場合がある
- exact frozen candidateから
INITIAL_RELEASE_ANCHORを作り、戻り先をproduction切替前に検証する - anchorへ一時Publishしたあと元deployへ復元し、復元後も同じhosting確認を通す
整理すると、
Exact Frozen Candidate
↓
INITIAL_RELEASE_ANCHOR
↓
Anchor URLで確認
↓
7 / 7 PASS
↓
一時Publish
↓
fresh session smoke
↓
元production deployへ復元
↓
7 / 7 PASS
です。
今回の結論は、
rollbackは「問題が起きたら考える手順」ではなく、公開前に戻れることまで確認しておく品質設計
です。
36. 次回
次回は、
「公開できる」を自動判定する――Release Gateを組み立てる【第45回】
です。
ここまで、
Vitest
Playwright
Chromium
WebKit
スマートフォン
A11y
IndexedDB
SPA fallback
production E2E
rollback
まで確認してきました。
しかし、
これらを個別に、
だいたい大丈夫そう
と判断していては、
正式公開判定が曖昧になります。
次回は、
これらを、
PASS条件
↓
一つのRelease Gate
としてまとめます。
つまり、
何が全部そろったら「正式公開してよい」と判断するのか
を扱います。
この記事を最後まで読んでいただき、ありがとうございます。
「いいね」を押していただけるとうれしいです。これからの記事づくりの励みになります。
もし気に入っていただけましたら、フォローもよろしくお願いします。
前の記事
第43回 localhostだけで終わらせない――production URLへ同じE2Eをかける
次の記事
第45回 「公開できる」を自動判定する――Release Gateを組み立てる
連載トップ
第0回 React＋TypeScriptで異世界RPGを作る――連載の目的と開発ロードマップ
note関連記事
公開する前に、戻れる場所を用意する #25
noteでは、初回正式リリースで過去の成功production deployが存在しなかったため、先に戻れる場所を作り、実際に切り替えて戻すところまで確認した背景を、制作側の視点から書いています。