Azure App Serviceのデプロイはこれで決まり。

AzureのApp Serviceでいざ本番を迎えるときに考えておくべきことがあります。

それは本番後のバージョンアップをどのように行うかです。

望ましいバーンアップの仕組みの条件は以下の通りです。

・人の手をできるだけ介在せずにバージョンアップできること
・本番前のテストを本番とほぼ同じ状況でテストできること
・本番環境への移行はできるだけ短い時間でできること

DevOpsの仕組みを作ろう

前述の条件を本番前に揃えるには、DevOpsな環境を構築するのをオススメします。

DevOpsな環境は開発の初期段階で構築することが望ましいです。

特に、スクラムなどのアジャイルで開発を進める場合は、スプリントごとに行うビューのために、ビルドする手間が増えます。

レビュー直前にビルドすると、ビルドエラーで焦ることにもなりますので、Pull Request時か、マージごとにビルドしておいて、早めに対応できるようにしておくべきです。

DevOpsの階層をどのくらいにするかは、考え方によって異なりますが、少なくても以下のような3階層で構築しておくと安心です。

・ビルド、テスト(ユニットテスト)、デプロイは、Azure DevOps、CircleCIなどのDevOpsで自動化します。
・developブランチのマージで検証環境をビルド、テスト、デプロイします。
・検証環境でのテストが完了した時点で、developブランチをmasterブランチにマージして、本番サブをビルド、テスト、デプロイします。
・適切なタイミングで、本番サブを本番環境と素早く切り替えます。

Azure App Serviceのデプロイスロットを活用しよう

GitHubのdevelopブランチから検証環境、masterブランチから本番サブの構築については、多少時間がかかっても構いません。

ビルド、テスト、デプロイというステップが必要なので、DevOpsで自動化されていれば大丈夫です。

本番サブから本番環境への切り替えは、できれば瞬時に行いたいところです。

これをAzureのApp Serviceで行うには、デプロイスロットを使います。

デプロイスロットはStandard以上のプランから利用できる機能で、本番環境を元に本番サブ、検証環境を構築できます。

さらに、本番サブから本番環境への切り替えは、スワップ(入替)するだけです。

また、スワップしたあとで問題が発生した場合は、再度スワップすることで元に戻すことができます。

デプロイスロットの設定方法

デプロイスロットを設定するには、本番のApp Serviceのデプロイスロットでスロットを追加します。

名前は、本番サブならmaster、検証環境ならstagingなどとします。

例えば、contract-minnasmileという本番に対し、stgというスロットを追加すると、contract-minnasmile-stgと言うApp Serviceが作成されます。

作成したデプロイスロットに対して、ビルド、テスト、デプロイを行うDevOpsを構築すれば完成です。

デプロイスロットは最低2つは必要

デプロイスロットは少なくても2つは必要です。

1つは本番と切り替えるために準備するリリース用のデプロイスロットです。

もう1つは、レビューやテストなどを行うためのデプロイスロットです。

今回、ご紹介した環境は、以下の理由からできるだけ初期の段階から構築することをオススメします。

・他に利用するサービスの構成をDevOpsができるように考えておく必要がある(もしくは、できるようなサービスをチョイスする必要がある)
・ビルドのエラーは早く見つけた方が原因の特定が行いやすい。
・ビルドの自動化は、開発の効率化に直結する。
・レビューの前日にビルドが通らず、徹夜しなくて済む。

プロジェクトの終盤になってDevOpsを始めると、DevOpsが実現できない可能性が高まるばかりか、開発時におけるメリットを享受できないので、もったいないです。