はじめに
masamoriです。今更感がありますが、ゼルダの伝説ティアキン始めました。いやー、面白い。寄り道ゲームとして最高の出来だと思います。考察についてはこれだけで3本ぐらいの記事になってしまうので、また別の機会に。
さて、最近Azure Functionsに触れる機会が多くなってきました。便利なんですよねこれ。何が便利かって、まずは使った分だけしかお金かからないってことですが、それよりもアプリケーション構成がものすごく考えやすくなったってことが便利です。
どういうことかと言うと、モノシリックにアプリを作る場合、全てのイベントを一つの大きなファイルにまとめなきゃいけないんですよね。後で機能を追加したい場合、そのアプリケーションのルールに従って書かなきゃいけないわけです。当然ですね。
しかし、Functionsのようなサービスを使う場合、イベント駆動的な処理はFunctionsに任せて、アプリは通信の出入り口を提供するだけで良かったりします。まぁ、Functionsを使いすぎると逆に依存関係が複雑になってしまうということもありえますが、その辺はバランスを見ながらの設計が必要ですね。
VSCode からFunction
前置きが長くなりましたが、Functionsを作成するときはVSCodeを使うと便利です。ローカルデバッグからデプロイまで全てVSCodeで完結できます。
コマンドを打つことなくAzureの環境にデプロイができます。便利ですね。なんならリソースグループ作ったりするのもVSCodeで出来てしまうので、Azure のportalでポチポチやる必要がなくなります。意外とVSCodeとportal画面を切り替えるのってストレスなんですよね。。
検証などでFunctionsを使用したい場合、このドキュメントのデプロイで十分だと思います。
しかし、例えば本番運用する前にステージ環境でFunctionsのテストをしたい場合もあると思います。というより、きちんと運用するならしないと。
ちなみに、App Serviceの場合、デプロイスロットという機能を使ってステージ環境と本番環境を容易に切り分けることができます。
これ、Functionsでも同様のことが出来ると分かりました。
スワップ操作は便利なので、早速ステージスロットを作成してローカルで作成したFunctionをステージ環境にデプロイしようとしました。
しかし、VSCodeからステージ環境にデプロイってどうやるんだと思い調べた結果です。
調査
実は、上記のデプロイチュートリアルの方法でデプロイすると、運用スロット(デフォルトで作られているスロット)に自動でデプロイされてしまいます。
しかし、Azureサイドバーからから作成したスロットにデプロイできます。
いたせり尽せりのVSCode。
終わりに
FunctionsにデプロイをするにはGtHubからでもできます。この辺はApp Serviceと一緒です。CD環境を構築したい場合はGItHubを使用してデプロイする方がいいと思います。GitHub Actions のfileも自動で作ってくれますしね。
サーバレスの場合って、この辺のCI/CDのベストプラクティスは気になるところです。いろんな人のブログ読んでいこう。
ちなみに、今回言及したようにApp ServiceやFunctionsにおいて、ステージ環境から運用環境にデプロイするにはスワップという機能が便利なのですが、これはまた別の機会にAzureが提唱するデプロイのベストプラクティスという形で記事にまとめようと思います。
