前提条件
今回はAzureのFunctions(Function App)を利用しますので、AzureのSubscriptionを保持しており、すでにFunction Appを１つ新規作成してある状態を前提としています。
はじめに
Pipelinesは、開発効率を圧倒的に高める上で大切なサービスです。
超概要につきましては、Azure DevOps Pipelines(パイプライン)の超概要をご覧ください。
Builds(ビルドパイプライン)単体につきましては、Azure DevOps PipelinesのBuilds（ビルドパイプライン）を使ってみるをご覧ください。
今回は、"Builds"からの"Releases"(リリースパイプライン)を実施したいと思います。
こちらのCIとCDになります。
今回は、Azure FunctionsというAzureのサービスを使って説明したいと思います。
Functionsに関するマイクロソフト公式ドキュメントはこちらをご確認ください。
FunctionsやWebAppsは独自にデプロイパイプラインを持てる（先に脱線した話題）
今回は"Builds"と"Releases"を使いますが、とりあえず自動デプロイしたいというだけであれば、特に"Releases"を使わなくてもリリースは可能です。
各々のサービスの中で設定する項目がありまして、リポジトリやブランチを指定してあげれば自ら変更をフックしてデプロイしてくれます。
本番環境への適用につきましては慎重にご検討いただきたいですが、ご参考まで。
Azure Functions の継続的なデプロイ
Azure App Service への継続的デプロイ
Functionsのチュートリアルをベースに実践
今回はチュートリアルをベースに、ビルドと開発環境へのリリースを実践してみます。
チュートリアルはこちらになります。
Azure DevOps を使用した継続的デリバリー
アプリケーションの作成
VisualStudioを使用して、HTTPトリガーで稼働するデフォルトのFunctionsアプリケーションを作成、メソッド１つとMSTestを追加しました。
Functionsの中に、このようなメソッドを１つ作って
MSTestを同一ソリューション内に新規作成して
テストを1行記載してみました。
今回も完成品をこちらのReposに置きました。
リポジトリ
MSTestについてちょっと知りたいという方は、とりあえずこちらをご確認ください。
単体テストの概要
"Builds"（ビルドパイプライン）の作成
1.リポジトリを作成
Azure DevOps PipelinesのBuilds（ビルドパイプライン）を使ってみる - Reposへ登録を参考にして、ご自身のReposに上記リポジトリをコピーしてください。
2.ビルドパイプラインを作成
今回もクラシックでいきます。
"Builds"画面で"New"します。
"Use the classic editor"をクリックしてください。
先ほどコピーしたリポジトリを選択します。
テンプレートでは"Azure Functions for .NET"を"Apply"します。
このままビルドしても良いのですが、せっかくなので単体テストも実施してみます。
"Agent job 1"と記載されている右側の "＋" をクリックします。
"MSTest"と入力し検索すると(しなくてもいいのですが)、"Visual Studio Test"が出てきますので"Add"します。
エージェントは、上から順番に仕事をします。
Add直後の状態だとArtifact（この作業の最終生成物）を発行した後でテストをしてしまいますので、"VsTest"をドラッグして"Build project"の直後に持っていきます。
これで、
- ソースコードを取得する
- ビルドする
- テストする
- 成果物をzipにする
- 最終成果物として発行する（後続のReleasesで利用できるようにする）
という一連の流れが出来上がりました。
ここからはエージェント実行時エラー対策です。
今回必要な、とりあえずの設定を記載していきます。
実際のプロジェクトではトライ＆エラーを繰り返すこととなりますので、最初は少し忍耐が必要です。
まずはテストが実行できない（実行ファイルが探せなくてエラーになる）ので探せるようにします。
VsTestの設定"Test files"の項に"test.dll"というのがありますので、"Test.dll"と変更します。
続きまして、アーカイブ対象となるファイルが探せないというエラーが出ますので、探せるようにします。
Archive files の設定"Root folder or file to archive"の項に"FunctionApp1/"を追記します。
画面上部中央"Save & queue"をクリックしてビルドします。
リリースパイプラインの作成（やっと本題）
ジョブが終わりましたら、画面右上の"Release"をクリックします。
ビルドパイプライン同様、こちらでもリリースパイプラインのテンプレートの選択画面となります。
今回は Functions ですので、"Deploy a function app to Azure Functions"をApplyします。
画面中央の "Stage 1"が選択されて、そこの設定ペインが出ている状態になっています。
とりあえず何も考えずに画面中央の"Stage 1"内、アラートアイコンが出ている"1 job, 1 task"というリンクをクリックします。
ここは、このStage 1という作業の内容について設定を行うリンクです。
リンク先はタスクの設定となっています。
今回の場合、Azure Functions Appを扱うことは理解してくれていますが、実際どこにデプロイするのかは指定されていません。
これがアラート表示の原因です。
こちらも、１つ１つ設定していきます。すでに作成済のFunctionsおよびそのFunctionsを作成したSubscriptionを設定ください。
終わりましたら、画面上部の"Save"ボタンをクリックします。
その後、左側の"Pipeline"タブをクリックします。
これで先ほどのリリースパイプラインの画面に戻りました。
ここまでの作業で、リリースパイプラインの作成が終わりました。
リリースパイプラインの実行
"Save"ボタンの右側にあった"Create release"ボタンをクリックしてみましょう。
何やら聞いてきますが"Create"ボタンをクリックします。
このような表示が出たら成功です。
青い文字のリンクになっている部分（今回だと"Release-1"）をクリックします。
うまくデプロイが完了した場合、画面中央のStageに"Succeeded"の文字が見えると思います。
まとめ
今回は、"Builds（ビルドパイプライン）"からの"Releases（リリースパイプライン）"の流れを実践してみました。
リリースパイプラインの基本は
- ビルドパイプラインにて生成された物を使う
- "リリース先を指定して生成物を配備する"という一連の流れ（パイプライン）を作成する
- パイプラインを何度も実行する
という動作です。
ローカルPCや人間に依存しないことは多くのメリットを生みます。
ローカルPC環境の保全を考えなくて良いですし、誰かがいないとリリースできないという状況もなくなります。
パスワード等をローカルで管理する物理も含めたリスクも回避できます。
作業履歴の管理も勝手に行われます。
BuildsもReleasesもコツは、生成物が小さいうちから実践することです。
また安定するまでは焦らないで１つ１つエラーを解消することです。
小さく生んで大きく育てる意識でご利用いただけたらと思います。