tech.guitarrapc.cóm

Technical updates

Azure Functions を GitHub と Continuous Integrationして自動デプロイされるようにしてみた

前回、Azure Functions を AWS Lambda を使っている一人としての視点で軽く触ってみました。

tech.guitarrapc.com

さて、作ったらデプロイですよね。*1かつ Github や CI とどのように連携するかは大事です。

見てみましょう。

目次

AWS Lambda の Configuration Deployment

ここでAWS Lambda を考えると、そのデプロイフローは極めて面倒です。

もちろん、AWS Lambda も Visual Studio + AWS Toolkit for Visual Studio | AWS を使えば、AWS Lambda に直接コードをデプロイも可能です。*2

しかし CI でほげもげして、となるとやはりつらいものです。以下のように試行錯誤をちょくちょく考えます。

qiita.com

aws.typepad.com

単純に GitHub に push したら、Lambda がデプロイされるように連携したいというケースが多いんですけどね。

Azure Functions の Continuous Deployment

では Azure Functions はどうでしょうか?

連携したい Azure Functions で、Function app settings を選択すると、Configure Continuous Integration というボタンが見つかります。ここから以下のソースと Webhookでのデプロイが可能になります。

これは、通常の App Service (Web Apps含む)と変わらず全く同じです。つまり、以前書いたような Kudu を使った Custom Deploy も可能ということです。

tech.guitarrapc.com

それでは、まっさらな Azure Functions に対して、Github から自動デプロイされるように CI を組んでみます。

Continuous Integration 設定

Github の master ブランチに pushしたら、自動的に Azure Functions にデプロイされるようにしてみましょう。つまり以下の図です。

同期に際して、同期先の Azure Functions と 同期元の Github リポジトリを確認しましょう。

同期先の Azure Functions は、作成したてで空です。

同期元の Github リポジトリは、以下に作成してあります。前回の記事のコードを、Github CI するにあたって支障がないようにディレクトリ構成を組んでいます。

github.com

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 をした後はポータル上は Read only

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 もこうしてほしいんですけどねぇ。

以下の記事と同様に、カスタムデプロイもいいでしょう。

tech.guitarrapc.com

もちろん、VSTS や Jenkins + MSDeploy も通常の Web Apps と一緒なので、簡単です。ただ、Web Deploy が必要になると厄介なので、CI サービスによっては使えなかったりします。とはいえ、そこで Local git を選ぶよりは Github がいいですね。

単純なケースであれば、ブランチを切って開発 > 各ブランチをCI > CIでテストも担保 > Pull Request を master にマージ > 自動的に Azure Functions へデプロイなどでもいいでしょう。

これで、作成、Github管理、CI まで通してみました。プレビューなので全面的とは行きませんが、本番で使えるレベルの高い完成度で動いています。

あとは、モニター機能を心待ちにしつつ、ぜひ皆さんも使ってみてください。*3

次回は、Nuget パッケージや npm パッケージの利用方法を見てみましょう。

tech.guitarrapc.com

*1:Web 上で書くとか初めの1回だけです。

*2:めちゃめちゃ便利なので、CI介さないなら最強

*3:いつどうして実行されたのか追えないと困るシーンは容易に予想されるので