ブログ

以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない)

体制

• 当日の体制は決まっているか
• 夜間立会いの場合、日中の営業時間の対応体制は決まっているか
• 翌営業日以降の体制は決まっているか
• 連絡担当と作業担当は分離されているか
• 作業担当はペア作業になっているか。作業者と確認者を定めているか
• 顧客の連絡先を抑えているか
• 顧客の連絡順番を抑えているか、お客様の当日の所在を抑えているか
• 顧客への連絡タイミングと方法を決めているか
  　（作業開始時、中間報告、サービス再開、確認完了、体制解除、障害発生、リリース遅延時など）
• 外部システムの担当者の連絡先を抑えているか
• データセンター等の監視の停止・再開の連絡先
• ビルへの入館やオフィスへの入館手配は済んでいるか

作業

• タスクの洗い出しは全て終わっているか
• タスクの作業時間の精査はできているか
• 複雑な作業やリスクのある作業は手順書を作っているか
• 複雑な作業やリスクのある作業は事前リハーサルが行われているか
• リリース後の確認手順は２段階に分けられているか
  • スモークテストレベル（まずはシステムが動作してそうかどうか）
  • 正常系および機能追加範囲（リリースした内容が正しいか）
• 外部システムや連携システムの確認ポイントは明らかか（当日以降の初回稼働含む）
• 作業時間には余裕が組み込まれているか
• 作業順序の依存関係の確認ができているか
• サービス停止時間内作業とサービス稼働中の作業に分離できているか
• 当日の作業チェックリストが用意されているか
• リリース対象ファイルの準備はできているか
• リリース対象ファイルの差分は意図したものになっているか
• DDL等は用意されているか（マイグレーションがない場合）
• 複雑な手順やSQL等はスクリプト化されているか（デプロイ自動化がない場合）
• 変更前の環境の全てのバックアップを取得しているか、また障害時にすぐ戻せるか
• 旧戻しの場合の作業所要時間が明らかになっているか
• リリースの申請等手続きは完了しているか

コンティンジェンシー

• 作業のチェックポイントと時刻を定めているか
• チェックポイントでの判断基準を定めているか
• リリースの続行および中止の判断基準を定めているか
• リリースを中止する場合の旧戻し手順を定めているか
• リリース続行・中止判断の顧客側決定者が明確か、お客様内で合意が取れているか
• 問題部位別のリリース判断基準があるか
  • （例）アプリに小さいバグが見つかったら？
  • （例）アプリに修正に数時間かかるバグが見つかったら？
  • （例）同時にサーバのハード障害が起こったら？
  • （例）特定の作業のみ遅延したら？