前回、Azure FunctionsをAWS Lambdaを使っている一人としての視点で軽く触ってみました。
さて、作ったらデプロイですよね。*1かつGitHubやCIとどのように連携するかは大事です。
見てみましょう。
- AWS LambdaのConfiguration Deployment
- Azure FunctionsのContinuous Deployment
- Continuous Integration設定
- 気になるポイント
- まとめ
AWS LambdaのConfiguration Deployment
ここでAWS Lambdaを考えると、そのデプロイフローは極めて面倒です。
もちろん、AWS LambdaもVisual Studio +https://aws.amazon.com/jp/visualstudio/を使えば、AWS Lambdaに直接コードをデプロイも可能です。
しかしCIでほげもげして、となるとやはりつらいものです。以下のように試行錯誤をちょくちょく考えます。
単純にGitHubにpushしたら、Lambdaがデプロイされるように連携したいというケースが多いんですけどね。
Azure FunctionsのContinuous Deployment
ではAzure Functionsはどうでしょうか？
連携したいAzure Functionsで、Function app settingsを選択すると、Function app settingsというボタンが見つかります。ここから以下のソースとWebhookでのデプロイが可能になります。
これは、通常のApp Service (Web Apps含む)と変わらず全く同じです。つまり、以前書いたようなKuduを使ったCustom Deployも可能ということです。
それでは、まっさらなAzure Functionsに対して、GitHubから自動デプロイされるようにCIを組んでみます。
Continuous Integration設定
GitHubのmasterブランチにpushしたらAzure Functionsへデプロイさせましょう。つまり以下の図です。
同期に際して、同期先のAzure Functionsと同期元のGitHubリポジトリを確認しましょう。
同期先のAzure Functionsは、作成したてで空です。
同期元のGitHubリポジトリは、以下に作成してあります。前回の記事のコードを、GitHub CIするにあたって支障がないようにディレクトリ構成を組んでいます。
Azure Functionsのディレクトリ構成
Visual Studio OnlineでAzure Functionsを一見して分かる通り、各Function区切りは単純なディレクトリです。
そして、CIするとそのAzure Functions全体が差し替わります。そこで、今回組んだGitHubのディレクトリ状態でGitHub CIを組めば、自動デプロイが問題なく動作します。
Azure FunctionsでGitHub CIを組む
早速組みましょう。
Azure Functionsで、Function app settings > Configure Continuous Integration > SetupからSourceをGitHubにして認証を通します。あとは、連携するリポジトリ、ブランチを選べばokです。
決定するとすぐに通知が飛び、
1分以内にデプロイが完了します。
Azure Functionsを選択し直すかRefreshすれば、デプロイされているのがわかるでしょう。
簡単ですね。いつも通りです。
ちなみにAzure FunctionsでGitHub CIを組んだ時に「GitHubのSettings > Webhook」を見ると、Web Appsの時と同じWebhook設定が追加されていることがわかります。
CIをした後はポータル上はReadonly
CIって、ようはデプロイソース元がマスタとして絶対になるということです。これは非常に重要な概念で、CIしているのにデプロイ先を勝手に触ると「次のデプロイで直接変更した箇所がCI元のソースで上書かれる」ということになります。つまり、GitHubなりVSTSなりなんでもCIをしたなら デプロイ先のSource Control されているコードを触るのは原則望ましくない結果を招きやすいということです。
Azure Functionsも、CIを組むとDevelopのコード上部に以下の表示となります。
Read only - because you have started editing with source control, this view is read only.
読んだ通りです。非常に良い対応だと感じます。おそらく、CIをしていて直接触るべきシーンはほぼ0かなと。Lambdaでもそうですしね。
ただ、コード部分が一見すると普通に見えるのはどうでしょうか。(実際はコードを直接入力できなくなっています。)
グレイアウトして選択に影響するのは困ります。それよりは全然いいですし、上部のRead only表示で気づけるものの、css でコード部分を背景を薄い灰色にするといった配色で示すのも良いのではないでしょうか。
気になるポイント
改善されると嬉しいポイントです。
Request Bodyはどこ？
Visual Studio Onlineのどこを見ても、Request Bodyに該当するファイルがないのです。なので、今回GitHub CIを組んでもこの通り空です。これなんとかならないのですかね？
逆にいうと、CIでのデプロイ結果に左右されないんですが、ちゃんと同期してくれた方が嬉しいです。
まとめ
デプロイに関しては、圧倒的なAzure Functionsの楽さです。AWS Lambdaもこうしてほしいんですけどねぇ。
以下の記事と同様に、カスタムデプロイもいいでしょう。
もちろん、VSTSやJenkins + MSDeployも通常のWeb Appsと一緒なので、簡単です。ただ、Web Deployが必要になると厄介なので、CIサービスによっては使えなかったりします。とはいえ、そこでLocal Gitを選ぶよりはGitHubがいいですね。
単純なケースであれば、ブランチを切って開発 > 各ブランチをCI > CIでテストも担保 > Pull Request を master にマージ > 自動的に Azure Functions へデプロイなどでもいいでしょう。
これで、作成、GitHub管理、CIまで通してみました。プレビューなので全面的とは行きませんが、本番で使えるレベルの高い完成度で動いています。
あとは、モニター機能を心待ちにしつつ、ぜひ皆さんも使ってみてください。*2
次回は、Nugetパッケージやnpmパッケージの利用方法を見てみましょう。
