前回のCIから、届ける段階へ
前回のR-08では、変更のたびに自動で検査を走らせるCIを学びました。ビルド、型検査、テスト、静的解析の四点がすべて緑になった変更は、次に本番へ届ける段階へと進みます。この講義は、その届ける仕組みであるCDと、届けたあとに問題が出たときの備えを扱います。検査で守り、配送で届け、いざというときは戻す。この一本の流れの後半を、ここで完成させます。
このスライドのポイント
- R-08で学んだCI＝変更のたびに自動で検査を走らせる仕組み
- 検査が緑になった変更は、次に「本番へ届ける」段階へ進む
- この講義の役割: 届ける仕組み（CD）と、届けた後の備え（ロールバック）を扱う
CD・リリース・ロールバックの定義
CD、継続的デリバリーとは、CIを通過した変更を、自動または承認一つでデプロイまで運ぶ仕組みです。リリースとは、利用者へ新しい版を届けることを指します。そしてロールバックとは、問題が起きたときに直前の正常な版へ戻すことです。デプロイの成果物が版ごとに保存されているため、戻す操作は即座に行えます。CIが検査、CDが配送、リリースが到着、ロールバックが差し戻し、と役割で覚えると混ざりません。
このスライドのポイント
- CD（継続的デリバリー/デプロイ）＝CIを通過した変更を、自動または承認一つでデプロイまで運ぶ仕組み
- リリース＝利用者に新しい版を届けること
- ロールバック＝問題発生時に直前の正常な版へ戻すこと
- 版ごとに成果物が保存されているから、戻す操作は即座にできる
なぜロールバックの発想が要るのか
この発想を知らないと、本番で問題が出たときに、原因を直してから再デプロイするという遅い一手しか思いつきません。修正には時間がかかり、慌てて直すと、かえって二次被害を招くこともあります。A-09で学んだ高リスク操作の原則を思い出してください。本番反映は、失敗したときに利用者へ及ぶ影響が大きい操作でした。だからこそ、まず戻す、直すのはそれから、という順番を運用の定石として先に持っておく必要があります。
このスライドのポイント
- これを知らないと、本番障害時に「直してから再デプロイ」という遅い一手しか思いつかない
- 慌てて直すと二次被害を招くこともある
- A-09の高リスク操作の原則: 本番反映は失敗時の影響が大きい
- 「まず戻す、直すのはそれから」を運用の定石として持つ
全体像——完成形パイプラインとロールバックの矢印
全体像を見ます。変更はまずCIで検査され、通過するとCDが本番へのデプロイまで運び、利用者へリリースされます。ここまでが前へ進む流れです。そこにロールバックの矢印を一本加えます。版nで問題が起きたら、保存されている一つ前の版n-1へ即座に戻します。A-09で予告した元に戻せる変更が、ここでデプロイという単位で実現されました。コードを一行ずつ戻すのではなく、公開された版そのものを丸ごと戻せる、というのがこの章の到達点です。
このスライドのポイント
- 前へ進む流れ: 変更→CI（検査）→CD（届ける）→リリース（利用者へ）
- そこにロールバックの矢印を一本加える: 版nで問題→版n-1へ即時復帰
- A-09の「元に戻せる変更」が、デプロイという単位で実現された
- 到達点: コード一行ではなく、公開された「版そのもの」を戻せる
処理の流れ——本番障害が起きた昼
処理の流れを具体例で追います。昼にリリースした変更のあと、経費申請が失敗し始めたとします。ここでの第一手は、原因調査ではなくロールバックです。直前の正常な版へ戻せば、数分で利用者の業務は復旧します。原因の調査は、P-08からP-10で学んだ切り分けの手順で、落ち着いてから行います。原因が分かったら修正し、CIを通してから、あらためてリリースします。戻すと直すを分けること。これが、被害の続く時間を最も短くする鍵になります。
このスライドのポイント
- 昼にリリースした変更で、経費申請が失敗し始めた
- 第一手は原因調査ではなく、ロールバック（数分で業務が復旧）
- 原因調査はP-08〜P-10の手順で、落ち着いてから
- 直したらCIを通し、再びリリース。「戻す」と「直す」を分ける
技術サンプルカード（diagram）
サンプルは、完成形パイプラインと障害時の二手順を一枚にした図です。上段は変更が検査、配送、リリースへと前へ進む流れ、下段は問題が出たときに、まず戻し、そのあとで直す流れです。読み方の要点は三つあります。ロールバックは版を戻すだけなので速いこと。原因調査と修正は必ずロールバックの後ろに置くこと。そして、データベースのマイグレーションが絡む変更はL-10で見たとおり戻しにくいので、特に慎重に扱うことです。AIへは、このサービスでロールバックする手順と、データベースの変更が絡むときの注意点を確認します。
このスライドのポイント
- 種別: diagram
- 目的: 完成形パイプラインの全体像と、障害時の二手順（戻す→直す）を一枚で確認する
- サンプル本体:
混同しやすい概念——ロールバックと修正リリース
混同しやすいのは、ロールバックと修正リリースです。ロールバックは版を戻す操作で、即座に終わります。修正リリースは原因を直して前へ進む操作で、検査や再デプロイの分だけ時間がかかります。本番障害の第一手は、原則としてロールバックです。まず利用者を正常な状態へ戻し、それから落ち着いて直す。この順序を取り違えないことが、被害を最小にするうえで何より大切です。
バイブコーディングでの確認点
バイブコーディングでの確認点です。リリースの前に、これはロールバックできる変更か、を必ず確かめてください。コードだけの変更は戻しやすいのですが、データベースの構造変更のように、戻しにくい類もあります。戻しにくい変更は、N-04で学んだ後方互換を保つ段階的なリリースとして計画します。AIへは、この変更はロールバックできますか、戻せない要素が含まれていますか、と聞いて、実行前に見極めます。判断だけをAIに委ねず、最後は人間が確認します。
このスライドのポイント
- リリース前に「これはロールバックできる変更か」を必ず確認する
- コードだけの変更は戻しやすい／データベースの構造変更は戻しにくい
- 戻しにくい変更は、N-04の後方互換を保つ段階的なリリースとして計画する
- AIへの質問例: 「この変更はロールバックできますか。戻せない要素が含まれていますか」
まとめと次回
一問一答です。本番で障害が起きたとき、第一手は何でしょうか。……答えは、ロールバックです。まず戻す、直すのはそれから、が合言葉でした。三十秒でまとめます。CIを通った変更をCDが本番へ運び、利用者へリリースし、問題が出たら版ごとロールバックで戻せる。これがA-09で学んだ元に戻せる変更の、公開段階での答えです。次回はカテゴリR最終回、動く環境ごと固めて運ぶコンテナへ進みます。関連資料は、Vercel公開 完全手順書と、バックアップと復旧入門です。なお公開サービスの画面は更新されることがあります。
このスライドのポイント
- 一問一答: 本番で障害が起きたときの第一手は？→ ロールバック（まず戻す、直すのはそれから）
- 30秒まとめ: CIを通った変更をCDが本番へ運び、リリースし、問題が出たら版ごとロールバックで戻せる
- これがA-09「元に戻せる変更」の、公開段階での答え
- 次回: カテゴリR最終回、動く環境ごと運ぶコンテナへ
- 関連資料: 「Vercel公開 完全手順書」「バックアップと復旧入門」
