3秒でわかる
作ったアプリをサーバーへ配置して利用できる状態にする作業。ビルドや設定反映、DB更新、再起動までを1つの手順としてまとめます。
30秒図解
もう少し詳しく
どういうものか
デプロイは、手元で動いているアプリケーションを本番のサーバーへ配置し、利用者からアクセスできる状態にする作業です。ファイルを置くだけで終わることは少なく、依存パッケージの取得、ビルド、設定値の反映、DBのマイグレーション、プロセスの再起動までを含めて1つの工程として扱います。
なぜ必要か
手元の環境と本番は、OSもバージョンも権限も違います。動いたコードをそのまま持っていっても、環境変数が無い、ポートが塞がっている、ビルド成果物が古い、といった理由で止まります。デプロイを手順として明文化し自動化しておくと、誰が実行しても同じ結果になり、問題が起きたときに戻せます。
具体例
# よくある最小構成の手順を1つのスクリプトにまとめる
set -e # 途中で失敗したら止める
<a href="/glossary/git-pull" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">git pull</a> origin main
npm ci # lock ファイルどおりに依存を入れる
npm run build
npx prisma migrate deploy # DB <a href="/glossary/schema" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">スキーマ</a>を反映
sudo systemctl restart myapp
<a href="/glossary/curl" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">curl</a> -fsS http://localhost:3000/health # 生きているか確認最後の疎通確認まで含めるのが要点です。再起動したという事実は、正しく動いていることの証明になりません。
つまずきやすいところ
本番だけで落ちる原因の上位は環境変数の設定漏れです。手元の .env はリポジトリに入っていないので、新しい変数を足した日は本番側にも足す必要があります。もうひとつは、先にコードを出してからDBを変更する順序の誤りです。新しい列を読むコードが、列の無いDBに向かって動くと全リクエストが落ちます。列の追加を先、削除を後に回すと安全です。
似た用語との違い
ビルドはソースを実行可能な形に変換する処理、デプロイはその成果物を配置する処理、リリースは利用者に公開すると決める判断です。機能フラグを使うと、デプロイ済みでも公開しない状態を作れます。
覚え方
デプロイは「置く作業」ではなく「戻せる状態で置く作業」です。前のバージョンへ戻す手順を先に用意し、実際に1回試しておくと、当日の判断が速くなります。
つまずきやすいところ(その2)
静的ファイルの入れ替えも事故になりやすい部分です。HTMLだけ新しくなってJavaScriptが古いままだと、参照先のファイルが見つからず画面が真っ白になります。ファイル名にビルドごとのハッシュを入れ、古い版もしばらく残しておくと、切り替えの最中に開いていた利用者の画面が壊れません。
作業の記録を残す点も忘れがちです。いつ、どのコミットを、誰が出したのかを残しておくと、障害が起きたときに切り分けの時間が半分になります。