開発チームから「本日デプロイしました」と報告が来たら、それは「本番環境への反映が終わりました」という意味です。コードを書き終えただけでは、実際のWebサイトやアプリは何も変わりません。デプロイは、作ったプログラムを本番環境に配置して、ユーザーが使える状態にする作業です。
工場で新商品を作っても、店頭の棚に並べるまでお客さんは買えません。運ぶ、検品する、値札を貼る、棚に並べる。デプロイは、この店頭に並べるまでの作業にあたります。一方、「いつお客さんに向けて売り出すか」を決めるのはリリースと呼ばれる別の判断です。2つの違いはデプロイとリリースの違いで詳しく整理しています。
デプロイに含まれる作業
開発者のパソコンや社内の検証環境で動いていたプログラムを、実際のサーバーへ移す。これが中心ですが、ファイルを転送するだけとは限りません。データベースの構造の更新（マイグレーション）や、設定の変更まで含むこともあります。
その手前には、プログラムを動かせる形にまとめる「ビルド」という工程があります。ビルドで作った完成品を、開発、検証、本番の順に各環境へ展開していく流れが一般的です。コンテナを使うと、どの環境にも同じ中身を確実に置けるので、「検証では動いたのに本番で動かない」を減らせます。
失敗しにくく戻しやすいデプロイ
本番に置く作業なので、失敗すればその瞬間から利用者に影響が出ます。だから、次の点を事前に決めておきます。
- 本番の前に、ステージングなどの検証環境で動作を確かめる手順
- うまくいかなかったとき、直前の状態へ戻すロールバックの手順
- 手作業を減らす自動化。人の手順が減るほどミスが減り、デプロイの頻度も上げやすくなる（CI/CD）
- サービスを止めずに切り替えるか（ゼロダウンタイムデプロイ）。止めるなら、いつ止めるか
新機能を届けるときも、バグの修正を急いで反映したいときも、この準備があるかどうかで、デプロイが「怖い作業」になるかどうかが決まります。