デプロイとは？ビルド・リリースの違い、デプロイの方法【図解】
アプリケーションをサーバー上で利用できるようにするための一連の作業をデプロイといいます。
システム開発では、開発工程が完了したら完成したモジュールを特定の環境で使えるようにする必要があります。つまりデプロイを行うことで、初めてアプリケーションが利用できるようになるのです。
目次
１．デプロイとは
英単語としてのデプロイ（英：deploy）は、「展開する、配置する」といった意味があります。
システム開発におけるデプロイとは、開発したアプリケーション（機能やサービス）をサーバー上に展開・配置して利用できるようにすることです。
Webアプリケーションであれば実行ファイルをWebサーバーやアプリケーションサーバーにアップロードして、その実行ファイルを実行することでサーバー上でアプリケーションを動くようになり、ユーザーが利用できる状態になります。この一連の作業がデプロイです。
つまりは、
- 実行ファイルを動かしたい環境に置く
- 実行ファイルを実行する
これらを行うことがデプロイです。
デプロイは基本的にアプリケーションの一時停止やサーバーの再起動を伴います。アプリケーションが利用できない期間（ダウンタイム）が発生するということです。アプリケーションを稼働させたままや、サーバーの再起動を伴わないデプロイは「ホットデプロイ」といいます。
２．デプロイ、ビルド、リリースの位置付けと違い
デプロイを行うためには準備が必要であり、準備の工程としてビルドというものがあります。そしてアプリケーションを公開する作業をリリースといい、リリース作業のなかの一工程としてデプロイがあります。デプロイも含めた全工程を行うことで、リリースが完了し、晴れてアプリケーションが世の中に公開されます。
この「ビルド」と「リリース」についてデプロイとの関係を含めて触れたいと思います。
２-１．ビルド
ビルドとは、デプロイに必要な実行ファイルを作ることです。
ソースコードをコンパイルして、各ファイル同士をリンクして一つの実行ファイルにまとめることを指します。デプロイではその実行ファイルを実行することで対象の環境にアプリケーションを展開します。このように二つの作業は切り離せない関係になっています。
リリースは、アプリケーションを公開することです。本番環境にリリースすればユーザーが利用可能になります。
ユーザーが利用可能な状態になるということはデプロイと同じこと？と思われるかもしれませんが、リリースとはデプロイも含めた様々な手順や段取りをまとめたものを指します。（プロジェクトにより内容は異なります）
例えば本章冒頭の図のような手順でリリースが行われた場合、
- アプリケーションを停止する
- デプロイを実施する
- デプロイ前後の状態を差分比較する
- サーバーを再起動する
- 動作確認する
という流れですので、デプロイはリリース作業の「一部」と言えます。
ホットデプロイでデプロイ作業のみでリリースが完了するような場合でも差分確認や動作確認といった基本的な作業は必ず行うので完全なイコールとなることはないと思って大丈夫です。
- リリースは新しいアプリケーションを公開するための工程をまとめた一連の作業のこと
- デプロイはリリース作業の中でアプリケーションを利用可能な状態にするための工程のこと
という感じで理解しておけば、いずれの場合も大きく間違うことはないです。
３．デプロイの４つの方法
デプロイと一口に言ってもその方法は様々です。
もしみなさんがプロジェクトの中でどうやってデプロイを行うかを考える立場になったとしたら、「無事にデプロイを完了させたい」と考えるでしょう。
そのときの参考となるよう、デプロイ方法をいくつか紹介します。
「無事」に完了させるために必要な要素を考えてみましょう。
- 早いこと（ダウンタイムなどユーザーに不便を与えない）
- 確実であること（デプロイに失敗しない、失敗してもすぐ元にもどせる）
- 安定的であること（時間や環境などの制約に縛られない）
などですね。（他にもあるでしょうが、ここではこの3点に絞ります）
このような観点も踏まえてデプロイについてさらに調べていくと、「継続的デリバリー」「継続的デプロイ」や「デプロイ自動化」といった言葉を目にすることになるでしょう。これらはいずれもデプロイを早く確実に、かつ安定的に行うために考案・実践されているものです。そしてその実現のための具体的な方法がこれから紹介するものたちです。それでは、ひとつずつ見ていきましょう。
３-１．ブルーグリーンデプロイメント
ブルーとグリーンという二つの環境をあらかじめ用意しておき、現在の本番環境をブルーで動かしたまま、新環境をグリーンにデプロイします。そして、デプロイが無事完了したらグリーンにスイッチのように切り替えることで旧環境から新環境へアップデートさせます。
新環境で問題が起こった場合は、再びブルーに切り替えることで簡単にロールバック（以前の状態に戻すこと）ができます。こうすることで、ダウンタイムをほぼ発生させることなく環境の切り替えが可能となります。
新環境に問題がない場合は、グリーンがそのまま本番環境として運用され、ブルーとグリーンの扱いが逆転します。（今までのブルーが今度はグリーンとなる）グリーン環境は次回のデプロイまで維持する必要があるため、運用コストが発生します。
３-２．イミュータブルデプロイメント
ブルーグリーンデプロイメントの手法を利用したものとして、イミュータブルデプロイメントがあります。
イミュータブルデプロイメントでは、新環境への切り替え後、問題ないことを確認したら旧環境は破棄します。デプロイのたびに新しい環境を作っては捨てる、ということを行います。ブルーグリーンデプロイメントと違い、イミュータブルデプロイメントでは旧環境の運用コストは生じません。
３-３．シンボリックデプロイメント
運用中のサーバー上の別の場所に新しいファイルを配置して、サービスが利用しているシンボリックリンクを変更することで新しいアプリケーションに切り替えます。
サーバーを増やす必要もなく低コストでデプロイを自動化できますが、ファイルによっては再起動が必要となる場合もあります。
３-４．ローリングデプロイメント
複数あるサーバーに対して順番にロードバランサーから切り離してデプロイを行っていく手法です。
一時的に新旧環境が混在することになるので気を付ける必要があります。
４．さいごに
デプロイは対象のアプリケーションの性質により必要な手順や工程が変わるため、プロジェクトによってプロセスが一定ではなく、結果として定義そのものも曖昧になりがちです。きっと、ここを読まれた方も「デプロイってよく聞くけど結局どういうことを指すの？？」と疑問に思われて検索したというケースが多いのではないでしょうか。
今みなさんが携わっているプロジェクトではどういう方法でデプロイされているのか正しく理解できるよう、この記事が参考になれば幸いです。
関連記事 関連記事 関連記事
コメント