リリース
制作・改修した内容を本番環境に反映して公開状態にすること。「公開」「ローンチ」とも呼ばれ、技術的な反映作業を指すデプロイとほぼ同義で使われる。CMSでは、ステージング(ステージング環境)で確認した内容を本番へ反映する、公開フラグを切り替える、といった形でリリースする。
基本はリリースの「手順とタイミング」を事前に握っておくこと。行き当たりばったりで本番に反映すると、確認漏れ・デグレード・告知とのズレが起きる。公開前チェックを通し、バックアップとロールバック手順を用意し、SNS / メルマガ告知と反映時刻を合わせるのが定石。
実務の論点はリリース手順書・反映時刻の事前共有・公開前チェックリストの通過・リリース直後の動作確認(スモークテスト)・問題時のロールバック判断・段階公開(一部ユーザー先行)の要否。アクセスが集中する告知と同時刻のリリースは、サーバ負荷で落ちるリスクがあるため避けるか、余裕を持たせる。
落とし穴は、リリース後の動作確認を怠ってデグレードの発覚が遅れること。ほかにも、ロールバック手順がなく緊急時に戻せない、ステージング設定(noindex / 開発タグ)が本番に混入、告知とリリースがぶつかってアクセス集中で落ちる、リリース手順が担当者の頭の中だけで属人化、といった点に注意する。
言葉をよく利用する人
- Web 担当者(発注側)
- ディレクター
- コーダー / フロントエンドエンジニア
- 情シス
- プロデューサー
会話上での使用例
リリース日程を業者と握る場面
-
Web 担当者
新ページのリリースはいつにしましょう
-
ディレクター
告知メールの配信時刻とは 2 時間ずらしましょう。公開前チェックを前日に通し、当日はリリース直後にスモークテストで主要動線を確認します
リリース直後に異常が出た場面
-
Web 担当者
リリース後、問い合わせフォームが送信できないと連絡が来ました
-
コーダー
すぐロールバックして公開前の状態に戻します。原因を切り分けてから再リリースしましょう。バックアップがあるので安全に戻せます