リリース後の確認から中止・切り戻しへ戻る矢印の図。戻す手順まで用意する

仕事・チーム開発

リリース手順書の書き方|作業・確認・切り戻しをセットにした記入例

「新しい版を配置する」「画面を確認する」「問題があれば戻す」。この三行だけでは、夜間に別の担当者が同じ作業を安全に実行できません。何を見て成功と判断し、どこで中止し、戻した後に何を確かめるかが抜けているからです。

この場面では、操作の列挙より、続行・中止・切り戻しを判断できる情報を優先します。 コマンドの羅列より先に、判断する人と観測する結果を決めます。

ここでは架空の問い合わせ管理アプリで、件名の文字数チェックを修正する小規模なWeb改修を例にします。対象はKubernetes上の inquiry-web Deployment、2レプリカ、DB変更なしと固定します。以下の sample-prod context、inquiry namespace、registry.example.invalid は説明用で、実在する環境への操作ではありません。実際の値・権限・承認者は自チームの手順に置き換えます。

作業を始める前に固定する情報

項目記入例
変更の目的件名101文字を保存できてしまう不具合を直す
対象と除外sample-prod の inquiry namespaceにある inquiry-web Deploymentの web コンテナだけ。DB定義変更・既存データ修正はしない
動作確認先社内ネットワークから開く https://inquiry.example.invalid/health と問い合わせ登録画面。.invalid は架空ドメイン
反映する版registry.example.invalid/inquiry-web:2026.09.23-rc2。直前版は registry.example.invalid/inquiry-web:2026.09.16。両タグは変更不可として管理し、事前に成果物の識別情報を作業票へ記録
実施窓9月23日 20:00〜20:30 JST。利用者への案内は別票で確認済み
役割実行者A、確認者B、続行・切り戻し判断者C
連絡先チームの所定チャンネルと当番表。個人の電話番号はこの共有文書へ写さない
着手条件検証環境で境界値テスト済み、直前版のイメージを再配置可能、Aの接続先が sample-prod と確認済み、監視パネル「受付API 5xx・直近5分」が更新中、反映前の5xxは0件

成果物の識別子を「最新版」と書かないのが重要です。実行時に最新版が変わると、何を反映したか追跡できなくなります。環境ごとの版と設定の対応を記録します。

記入済みのリリース手順表

リリース手順の4つの欄。作業:誰が何をする。確認:正常をどう判定する。中止:止める条件を明記。切り戻し:戻した後も確認する
リリース手順の4つの欄。中止条件と判断者を先に決める
順作業と担当期待する結果・証拠止める条件
1Aが作業開始を連絡し、下記の事前確認コマンドを実行接続先 sample-prod、稼働イメージは直前版、2レプリカがReady、監視パネルの直近5分の5xxは0件接続先・版が不一致、Readyが2未満、監視データが2分以上更新されない
2Aが下記の反映コマンドを実行し、rolloutを待つ120秒以内にrollout成功、Deploymentのイメージが 2026.09.23-rc2、2レプリカがReadyrolloutが120秒で終わらない、版が違う、Readyが2未満
3Bがテスト用アカウントで件名100文字・101文字を各1回登録100文字は1件登録、101文字は項目エラーで0件登録。既存の一覧を表示できるいずれか1件でも期待と違う、一覧が開かない
4Bが監視パネルとアプリログを反映後5分間確認受付APIの5xxは0〜2件、監視データは更新中。疑わしい応答の時刻・IDを記録直近5分の受付API 5xxが3件以上、ヘルスチェックが1回でも失敗、監視データが2分以上更新されない
5Cが20:30までに続行か切り戻しかを決め、Aが結果を周知判断、時刻、版、動作確認・監視の証拠を作業票へ残す判定不能のまま20:30になる

この表の閾値と版は説明用です。実案件では通常時の件数・利用量・監視遅延から閾値を決めます。配備直後だけの静かな画面を成功の証拠にしてはいけません。

例の事前確認と反映は次の操作です。作業票にはコマンドの出力と実行時刻を残します。get deployment の結果が想定と違うときは、次の set image を実行しません。

kubectl --context=sample-prod -n inquiry get deployment inquiry-web
kubectl --context=sample-prod -n inquiry get deployment inquiry-web -o jsonpath='{.spec.template.spec.containers[0].image}'
kubectl --context=sample-prod -n inquiry set image deployment/inquiry-web web=registry.example.invalid/inquiry-web:2026.09.23-rc2
kubectl --context=sample-prod -n inquiry rollout status deployment/inquiry-web --timeout=120s
kubectl --context=sample-prod -n inquiry get deployment inquiry-web -o jsonpath='{.spec.template.spec.containers[0].image}'

get deployment の READY は 2/2、前後のイメージはそれぞれ作業票の値と照合します。Bは社内ネットワークから GET /health のHTTP 200も確認します。テスト用アカウントで作った問い合わせIDも控え、登録件数を画面の見た目だけで判定しません。Kubernetesの公式手順でも、set image、rollout status、rollout undo が更新と復旧の操作として示されています。

切り戻しは「前の版を入れる」で終わらない

切り戻す場合はCが判断し、Aが確認済みの直前版を明示して反映します。どの改訂へ戻るかを曖昧にしないため、この例では rollout undo へ任せず、作業票で固定したイメージを指定します。

kubectl --context=sample-prod -n inquiry set image deployment/inquiry-web web=registry.example.invalid/inquiry-web:2026.09.16
kubectl --context=sample-prod -n inquiry rollout status deployment/inquiry-web --timeout=120s
kubectl --context=sample-prod -n inquiry get deployment inquiry-web -o jsonpath='{.spec.template.spec.containers[0].image}'

その後Bが旧版のイメージと READY 2/2 を確認し、ヘルスチェックとテスト用アカウントでの通常登録・一覧表示を再実行します。受付API 5xxの直近5分が事前の基準へ戻ったことも確認します。旧版には「101文字を受け付ける」という既知の不具合が残るので、101文字の拒否を切り戻し成功の条件にはしません。Cは修正が未反映であること、暫定対応、再リリースの担当を連絡します。

切り戻し後に見るもの理由
稼働中の版と設定旧イメージ、2レプリカのReady、設定が想定どおりかを確認
主要な登録・参照操作既知の不具合を除き、テスト用アカウントで通常登録と一覧表示ができるか確認
変更中に保存されたデータテスト用IDと本番利用者の登録結果を確認。版を戻しても、作られたデータは自動では戻らない
ログ・監視と利用者連絡受付API 5xxの直近5分、ヘルスチェック、既知の不具合と暫定対応を確認・周知

特にDB変更や外部サービスへの送信を含むリリースでは、アプリを一つ前の版へ戻すだけで整合性が回復するとは限りません。移行・データ・接続先ごとの復旧手段を別に設計し、事前に検証します。Google Cloudの移行手順も、ロールバック後にアプリをテストし、外部の変更も戻ったか確かめることを勧めています。

「成功」の基準を狭くしすぎない

今回の修正だけを見れば、101文字が保存されなくなった時点で成功に見えます。しかし、100文字以下も登録できなくなっていれば失敗です。変更箇所と、その周辺の通常操作を少数でも確認します。

逆に、すべての機能を手作業で確認しようとすれば、作業窓内に終わりません。変更に近い重要経路、監視で拾う異常、継続観測に回す項目を分けます。実行者が不明な結果を見つけたら、手順書にない操作を足す前にCへ相談します。

次のリリースへ残す

手順書を一度使ったら、予定と実際の時刻、止まった箇所、判断に迷った理由を追記します。成功した場合も「何を見て成功としたか」を残せば、次の担当者が改善できます。

次にリリース票を作るときは、各作業の横へ期待する結果と止める条件を一行ずつ書き加えてください。そこが空欄の工程は、当日に判断を現場へ丸投げしている可能性があります。

-仕事・チーム開発
-