2.3リリース及び展開管理

変更管理が「その変更を行ってよいか」を決めるプロセスだとすれば、リリース及び展開管理は「承認された変更を、どの単位でまとめ、どうやって本番環境へ安全に届けるか」を担うプロセスです。同じ承認済み変更でも、一度に全ユーザへ配布するのか、一部から段階的に広げるのかで、失敗したときの影響範囲はまったく変わります。この節では、リリース単位の設計、展開方式の選択、そしてビルド・テスト・展開の分離という観点から、稼働中サービスへの配布をサービスマネージャがどう計画・判断するかを学びます。

2.3.1リリース単位とビルド・テスト・展開

• リリース単位＝一度にまとめて本番へ移す変更のかたまり。関連する変更をまとめて1つのリリースにすると調整・テストが一度で済む一方、まとめすぎると失敗時の切り分けが難しくなり切り戻しも重くなる。逆に細かく分けすぎると調整回数が増える。影響範囲とテスト・切り戻しのしやすさのバランスで単位を設計する。
• ビルド・テスト・展開の分離＝本番へ展開する前に、本番と同等の環境でリリースをビルド・テストして品質を確認する。テスト済みの成果物をそのまま本番へ展開することで、本番でのみ発生する差異を減らす。テストを経ないまま本番へ直接展開する運用は、リリース起因のインシデントを増やす。

2.3.2展開方式の選択

• 一括展開（ビッグバン）＝全対象に一度に展開する方式。展開が短期間で済み全ユーザの状態が揃う利点があるが、失敗すると全ユーザへ一斉に影響が及ぶ。影響が小さい・十分に検証済みのリリースに向く。
• 段階的展開（フェーズド）＝対象を分割し、一部から順に広げる方式。パイロット（限られた利用者・拠点で先行導入し、問題がないことを確認してから全体へ広げる）を含む。失敗の影響を一部にとどめ、問題を早期に検知して残りの展開を止められるため、影響が大きい・不確実性の高いリリースに向くが、全体完了まで新旧が混在する期間が生じる。

あるサービスマネージャが、全国100拠点で使われている業務システムに、承認済みの大規模な機能改修リリース（画面刷新と業務ロジックの変更を含む）を本番展開するにあたり、リリース単位と展開方式をどう設計するか判断しています。まずリリース単位について、今回は画面刷新とロジック変更が相互に依存しているためこれらは1つのリリースにまとめる一方、同時期に予定されていた無関係なマスタデータ更新はリリース単位を分け、万一いずれかが失敗しても切り分けと切り戻しを容易にする判断をします。次に展開方式ですが、変更は影響範囲が広く、実利用でしか顕在化しない不具合の可能性が残るため、全100拠点へ一度に配る一括展開は失敗時に全拠点の業務が同時停止するリスクが大きすぎます。そこでまず数拠点をパイロットとして先行展開し、実業務での動作・性能・問い合わせの発生状況を一定期間モニタして問題がないことを確認したうえで、残りの拠点へ段階的に広げる方式を採ります。この方式なら、パイロットで重大な問題が見つかった場合に残りの展開を止め、影響を数拠点にとどめて切り戻せます。ただし段階的展開では、展開済み拠点と未展開拠点で新旧のバージョンが混在する期間が生じるため、拠点間でデータをやり取りする業務に不整合が出ないか（新旧フォーマットの互換性）を事前に確認し、必要なら移行期間中の互換対応を用意します。さらに、いずれの展開でも本番と同等のステージング環境でビルド・テストを済ませた成果物を用い、各段階に切り戻し計画（そのバッチの展開を取り消して旧バージョンへ戻す手順と判断期限）を紐付けます。このように、リリース及び展開管理の判断は「承認された変更をただ配る」ことではなく、リリース単位の切り方・展開方式（一括か段階的か）・新旧混在への配慮・切り戻しの備えを、リリースの影響度と不確実性に応じて設計することにあります。

2.3.3この節のまとめ

• リリース及び展開管理は変更管理で承認された変更を本番へ安全に配布する（変更の可否判断は変更管理の役割）
• リリース単位は影響範囲とテスト・切り戻しのしやすさのバランスで設計し、本番前にビルド・テストで品質を確認する
• 展開方式は一括か段階的（パイロット含む）かをリリースの影響度・不確実性で選び、影響が大きいほど段階的展開で局所化する