Azure App Service にデプロイする方法はいくつかあります。
皆さんはどのような方法を選択していますか?
- Web デプロイ
- パッケージ(Zip)デプロイ
- FTPデプロイ、etc…
はじめに
私の担当する製品は、開発環境に VisualStudio を利用しているため、親和性が高い Web デプロイまたはパッケージデプロイが候補となります。
最近は社内で Github への移行が進んでいるため、Github Actions を利用したデプロイも可能になりましたが、現状では社内システム(Jenkins)からの定時デプロイで構築されています。
近いうちに Github Actions への移行も予定していますが、今回の記事は、通常の Web / パッケージデプロイについてのお話です。
ちなみに、FTP デプロイは「シンプル」「高速」というメリットはありますが、依存関係の復元(nuget / npm 等)がサポートされていなかったり、セキュリティ面で弱い部分があったりと、私のプロジェクトでは採用していません。
メリット / デメリット
さて、早速ですが、以下に Web デプロイ / パッケージデプロイ についてのメリット、デメリットを私なりにまとめてみました。
Web デプロイ
メリット
- 差分デプロイ:変更されたファイルのみをアップロードするため、変更ファイル数が少ない場合はデプロイ時間が短縮されます。
- ファイルの更新日時(JST):ファイルの更新日時がビルド時の日本時間でデプロイされます。
デメリット
- Windows 依存:Web デプロイ は Windows 環境に依存しており、Linux や macOS では利用できません。
パッケージデプロイ(Zip)デプロイ
メリット
- プラットフォーム非依存:どのOSからでもデプロイが可能です。
- シンプル:Zip ファイルを作成してアップロードするだけでデプロイが完了します。
デメリット
- 全ファイルのアップロード:差分ではなく、毎回全ファイルをアップロードするため、大規模なアプリケーションではデプロイに時間がかかる可能性があります。
- ファイルの更新日時(GMT):ファイルの更新日時がビルド時の GMT 時間でデプロイされます。
メリット・デメリットまとめ
プラットフォーム依存
Web デプロイ は、Windows用デプロイツールのため、Linux では利用できません。
その点、パッケージデプロイ はプラットフォームに依存しないため、Windows / Linux いずれにも対応可能です。
アップロード単位
Web デプロイ では、変更が入ったファイルのみが対象になるため、必要最低限のアップロードになります。
逆に、パッケージデプロイ では、必ず全ファイルが対象となるため、アップロード容量が増え、時間がかかる可能性があります。
ただし、Web デプロイ でもファイルの変更量が多い場合、アップロード量が増えます。
その結果、パッケージデプロイ と同等の時間がかかる可能性があります。
また、アップロード回数が増えることで、アップロードに失敗し、デプロイが失敗するリスクも増えるため注意してください。
ファイルの更新日時
Web デプロイ では、ファイルそのものをアップロードするため、更新日時はビルド時間と同時刻のままです。
その点、パッケージデプロイ では、アップロード後に展開するため、サーバー側のタイムゾーン(GMT)に依存します。
日本時間(JST)で考えると、GMT とは9時間差があるため、ファイルの更新日時を利用したロジックを実装している場合には注意が必要です。
結局どっちが良いの?
ちなみに、私のプロジェクトでは、Web デプロイ の場合にアップロード対象のファイルがサーバー側でロックされてしまい、更新できずにデプロイ失敗となることが結構な頻度でありました。。。
この現象を回避するために、パッケージデプロイ を採用しています。
まとめ
Web デプロイ / パッケージデプロイ、それぞれメリット、デメリットがあることが分かります。
いろいろな開発環境があるので、皆さんの環境に合わせたデプロイ方法を選択してくださいね。
おわりに
KENTEMでは、様々な拠点でエンジニアを大募集しています!
建設×ITにご興味頂いた方は、是非下記のリンクからご応募ください。
recruit.kentem.jp
career.kentem.jp