デプロイ

🐾 猫で例えると？

小さな木の箱に入り、手足をはみ出させている茶トラ。猫をアプリ、箱を動かす環境とすると、箱へ配置することがデプロイに当たります。写真のはみ出した手足からは「配置できても、余裕があるとは限らない」点も連想できます。アプリも配置後に、必要なメモリや設定が揃っているかを確かめます。

💻 IT現場における「デプロイ」とは？

Webサービスではビルドしたファイルやコンテナーなどを配備します。静的サイトならDB接続もアプリの再起動も不要な構成があります。何を配備するか、環境ごとの差をどこで設定するかを明確にしておくと再現しやすくなります。

よく「リリース」という言葉と混同されますが、デプロイはあくまで「サーバーへの配置作業」というエンジニア視点の技術的な行為を指し、リリースは「ユーザーに向けて公開・発表する」というビジネス視点の意味合いが強くなります。現場では「深夜2時に本番サーバーへデプロイして、翌朝10時に新機能をリリースする」といった使い分けをします。

⚠️ デプロイの仕組みと注意点

手元で動作確認できたプログラムでも、本番では設定や権限、依存するサービスが異なり、動かない場合があります。写真の茶トラのように、本番サーバーのメモリ容量（箱のサイズ）に対してアプリケーション（猫）が大きすぎると、サーバーが処理しきれずにダウンしてしまう（OOM：Out Of Memory）リスクもあります。

自動デプロイ（CI/CD）の導入

昔はFTPソフトを使って手作業でファイルをアップロードしていましたが、現在はミスを防ぐために自動化するのが主流です。

配備の流れの一例（製品共通の実行コードではありません）
1. 対象のコミットと依存関係を確定
2. 必要なテストとビルドを実施
3. 同じ成果物を検証環境で確認
4. 設定・データ移行・戻し方を確認
5. 本番へ配備してヘルスチェック
6. エラー率や主要操作を確認し、問題があれば所定の復旧へ

CI/CDで自動化できる範囲は、実際に定義した工程だけです。mainへpushすればテストも復旧も自動的に備わるわけではありません。認証情報や接続先を適切に管理し、成功の判定と停止条件もワークフローへ入れます。

🛠️ デプロイを賢く使うためのポイント

いかにサービスを止めず、かつ失敗した時にすぐ元に戻せる（ロールバックできる）設計にしておくかが重要です。

• 切替方式を選ぶ： ブルーグリーンは新旧の環境を用意して切り替える方法です。接続中の処理、DBの互換性、キャッシュなども考慮しなければ、切替だけで無停止を保証できません。
• リソースの見積もりと監視： 本番環境に配置する前に、アプリケーションが消費するメモリやCPUを正確に把握し、サーバーのスペック（箱の大きさ）が適切か確認する。
• 戻せる範囲を確認： アプリの版を戻しても、変更したDBや外部への送信は戻らない場合があります。旧版でも読めるデータ移行や、復旧手順を事前に確認します。

箱に収まる茶トラのように、アプリにも動かす環境との相性があります。公開前に設定や必要な資源を確認し、公開後には主要な操作とログを確かめましょう。問題が出たときに、どの版へどう戻すかも用意しておきます。