第23章本番リリース判定

この章では、作ったものを「本番相当へ出してよいか」を判断する型を学ぶ。ここでは、研修の外でも通用する一般的な専門用語だけを取り上げて解説する。

artifact

読み：アーティファクト／artifact
一言で言うと：確認やリリースの対象になる具体的な成果物である。
くわしく：artifactは、PR、commit、build済みのcontainer image、配布ファイル、生成されたrelease noteなど、後から「どれを確認したのか」を特定するための対象を指す。PRRでは、動作確認した差分と実際に出す差分がずれると判断の根拠が崩れる。厳密なimage tagを使わない研修でも、PR番号、commit SHA、作業branch、提出ファイル名を記録すると追跡しやすい。
具体例：支援ステータス機能で、feature/status-filter branchの特定commit、またはECR image tagをrelease candidateのartifactとして記録する。
つまずきやすい点：「localで見た」で終えると、後からどの差分を見たのか分からない。可能な範囲でPR、commit、image tag、提出ファイル名を残す。
テキスト本文での登場箇所：第23章「Release Candidateを固定する」

読み：ブロッカー／blocker
一言で言うと：このまま出すと大きな問題が起きるため、出す前に直すべき項目である。
くわしく：blockerは、利用者、安全性、運用に重大な影響があり、リリースを止める理由になる課題を指す。残っていてもよい課題（受容するリスクや後で追うfollow-up）と区別するために使う。blockerがあるなら、出すより先に直す。何がblockerで、なぜそう言えるかを説明できることが大切である。
具体例：支援ステータス機能で、不正なstatusを保存できる、secretがログやREADMEに出ている、既存ログが表示されない、といった問題はblockerになる。これらが残るなら出さない。
つまずきやすい点：すべての不安をblockerにすると何も出せなくなる。影響の大きさで、blocker、受容するリスク、follow-upに分ける。
関連語：go / no-go（第23章）
テキスト本文での登場箇所：第23章「Security Readinessは危ない使い方を防ぐ確認である」

読み：ゴーノーゴー／go / no-go
一言で言うと：出してよいか、止めるかを決めるリリース可否のゲート判断である。
くわしく：go / no-goは、意思決定の場で「進める(go)」「止める(no-go)」を明確に選ぶための一般的な言い方である。気分や雰囲気ではなく、証拠、影響、残課題、追跡方法で決める。goは進めてよい、no-goはblockerがあるので今は出さず先に直す、という判断になる。なお本書ではgoとno-goの中間に「go with follow-up」（追跡すべき残課題を明示して進める）という選択肢を置いているが、これは本書独自の整理であり、基本はgoかno-goの可否判断と考えるとよい。
具体例：支援ステータス機能のPRRで、主要フローとsecurity確認が通り、blockerがなければgoにできる。逆に不正statusを保存できるならno-goにする。
つまずきやすい点：判断を後回しにして「だいたい大丈夫」で出すと、根拠が説明できない。何を確認したか、何を受け入れたかを示してから判断する。
関連語：blocker（第23章）
テキスト本文での登場箇所：第23章「Release Decisionは証拠とリスクで書く」

読み：スモークテスト／smoke test
→ 第16章を参照。
本章での補足：本章では、リリース直後に短時間で主要動線が生きているかを見る最小確認として使う。すべてのテストを再実行するのではなく、「出した直後にこれが通らなければまずい」という確認を三つ程度に絞る。支援ステータス機能なら、一覧表示、needs-help絞り込み、新規ログ作成を一つずつ確認できる。
テキスト本文での登場箇所：第23章「Smoke Testは短く主要動線を見る」

読み：ランブック／runbook
→ 第16章を参照（詳しい定義は第16章に譲る）。
本章での補足：本章では、リリース前、リリース中、リリース後、問題時対応、rollback、cleanupの手順をまとめた手順書として扱う。問題が起きたときに読むものなので、長い背景説明よりも、手順と判断条件を短く書く。支援ステータス機能なら、出す前の確認、出した後のsmoke test、一覧が開かないときの対応、戻し方までを並べておける。
テキスト本文での登場箇所：第23章「Operations Readinessは手順どおり動かせるかを見る」

読み：ロールバック／rollback
→ 第16章を参照。
本章での補足：本章では、release runbookの一部として、問題発生時に前の状態へ戻す方針を用意しておくことを扱う。データ変更がある場合は、戻したときに既存ログが読めることを先に確認する。
テキスト本文での登場箇所：第23章「Operations Readinessは手順どおり動かせるかを見る」