DevOpsでAzure FunctionsにAPIをデプロイしてみました（C#編）
本ブログでおよそ１か月前からDevOpsを使い始め、更にその前はVS CodeによるAzure Functionsへのデプロイを勉強してきました。
ここまでの知識の積み重ね、集大成として、いよいよAzure Functionsに対してDevOpsを使ってAPIのプロジェクトをデプロイしてみたいと思います。
まずはC#編となります。
一部内容がかぶる部分もありますが、この記事にいきなり辿り着く方もいらっしゃるかと思いますので、振り返りも兼ねて少し細かく手順を書いていきたいと思います。
まずはプロジェクトに関して。MicrosoftのGitHubで似たようなプロジェクトを探すことも考えたのですが、経験上一番手っ取り早い方法として過去の記事でも扱ったVSCodeによって作成できるサンプルプロジェクトを利用したいと思います。
まずはVS Codeを立ち上げて、左側のタブのAzureアイコンを選び、以下の「WORKSPACE」の赤枠部分の「＋」部分をクリックし、更に「Create Function」を選びます。
すると以下のようなダイアログが出るので「Create new project」を選びます。
そして、以下の部分で言語は「C#」を。。
次にフレームワークは「.NET6.0」を選びます。
そして、テンプレートは色々ある中から「HTTP trigger」を選びます。
選択肢が以前の内容より増えたような気がするのですが、気のせいでしょうか。。
色々面白そうなものが並んでいます。が、まずは「HTTP trigger」です。
そしてその後も選択を行ってサンプルプロジェクトが作成されますが、エラーが出ているようなのでふと画面右下を見ると以下のような警告が出ているので「Restore」を選んで依存性を解決します。
そして再度ビルドを行い、localhostの以下のURLで立ち上がったことが確認できます。
まずはブラウザで開いてみて。。
ローカル環境で動作するPostman AgentでAPIを叩いて、正しく応答が返ることを確認します。
ちなみにこのサンプルAPIはプロジェクトはJSON形式で「name」キーのValueの内容を「Hello xxxx,」の「xxxx」に設定して応答を返すAPIです。
ということでサンプルプロジェクトを作成して、ビルドとローカルでの動作確認ができたところでDevOpsのAzure Reposにプッシュしてみましょう。
こちらもGitに不慣れな方は以下のURLを参考にしてみてください。
完全に空の状態からではなく（その方法も載ってますが）、既存のプロジェクトをGitリポジトリにPushする方法が書かれています。
そして、以下のようにAzure ReposにPushすることが確認できました。
ここで今更かもしれませんが、Azure側の今回Functionsを作成したいサブスクリプションにFunctionsをあらかじめ作っておいてください。
そして次にPipeline、YAMLを作るわけですが、上の画面で「Set up build」というボタンに気付きました。
もしかして、これでデプロイはともかくとして最低でもビルドまではパイプラインを作れるのかしら。。？
ということで押してみますと以下のような画面が表示されます。
そして、内容を見てみると、そもそもの目的であった「.NET Core Function App to Windows on Azure」という選択肢が出てきましたのでこれ幸いとばかりに選択してみます。
そして以下のような画面になり、デプロイ対象となるサブスクリプションを選択します（都合上サブスクリプションの情報は隠しています。。すみません）。
サブスクリプションを選択後、以下の画面になりますので既に作成済みのFunctionsを選択します（忘れていた方はAzureポータルでFunctionsを作成後、一旦前の画面に戻って再度以下の画面に戻ってくれば対象のFunctionsを選べるようになります）。
すると以下のようにPipelineのYAMLが作成されます。
見切れてしまっていますが、Azure Functionsへのデプロイも嬉しいことに生成されています。
「よしよし、いいぞいいぞ」とほくそ笑みつつ、上の画面右上の「Save and run」を押して実行します。
以下の画面が出るので「Save and run」を押すと。。
以下のようにいよいよPipelineが実行されました。
てっきりこのままデプロイまで進んで無事しゅーりょー（終了）と思いきや、エラー発生。。
以下のスクショでは見切れてしまってますが、エラー文章を見てみると、
「the current .NET SDK does not support targeting .NET Core XXXX」
というような内容で、どうやらビルド環境が.NET Core6.xじゃなく、5.xなのでダメだった。。ということ。
ええ。。ビルド環境変えるのってどうやるの。。？
とググってみると以下の記事に。
このAnswerの部分を見てみるとWindows 2019 イメージでの .NET 6 の使用はサポートされておらず、Windows 2022で動作させる必要があるとのこと。
確かにYAMLを見るとVMイメージ名として「windows-2019」が設定されていたのでこれを2022に変えてみます。
こんなんでビルドが通るようになるのかしらと半信半疑で再度試してみると無事ビルドどころかデプロイまで成功しました！
そしてPostmanでFunctionsのURLからAPIを叩いてみて、ちゃんとデプロイされていること、動作することを確認できました！
ということで、ここまで辿り着くまでに色々とありましたが、なんだかんだで今までの集大成のような形で知識、技術を生かし、目的を達成することができました。
どれもそれぞれ別々にではありますが成功してきたものなので、そんなに感動は無さそうな気がしていましたが、それでもやはり嬉しいものですね。
さて、このAzure FunctionsによるAPIの構築ですが、この規模であればDevOpsを使うのは少々大仰かもしれません。
仮にそれなりのプロジェクトのスタブAPIだとしても、私が以前記事に書いたVS Codeからのビルド・デプロイで十分ではあります。
ただ、仮にこのAPIを書いた人が休んでしまって、その日にどうしてもAPIを修正したいとなった場合は共通のGitリポジトリで管理した方がよいですし、それがAzure DevOpsでデプロイできるのであればDevOpsに登録されたメンバーであれば誰でもデプロイが可能です。
結論として「プロジェクトによる」と言ってしまえばそこまでですが、１人プロジェクトでない限りは（引継ぎをを考えると「１人プロジェクトであっても」ですかね）できればAzure DevOpsのような形で管理した方がよいかもしれません。
ということで今回の記事はこれで終わりたいと思いますー。