前回はシンプルに1ファイルで ASP.NET Core の Web アプリを Azure の Web Apps にデプロイする Multi-stage pipeline を作りましたが、今回は再利用できるようにテンプレートするという、自分用メモです。
それにしても、このブログ書きかけてから2週間ほったらかしてしまったなぁ...（遠い目）
テンプレート化をするとは...
パイプライン定義の YAML ファイルを分けてパラメーターを受け取れるようにすることで、再利用できるようにするって話です。
色んな開発をしてても実際に pipeline なんて似たようなことをやることもよくあるのでやった方がいいやつですね。テンプレート化の粒度は以下2パターンです。
- Jobs をテンプレート化する。つまり、複数の Job を定義できます。
- Job をテンプレート化する:。複数のstep をテンプレート化します。
書き方は前回のブログで書いたような普通に書くのとほぼ変わらないです。
基本的には、ASP.NET Core の Webアプリを Azure の Web Apps にデプロイするシナリオですが、今回テンプレートを利用して作成するのはこんな Pipeline です。
- Test and Build stage: テストとビルドをしてデプロイ用の Artifact を生成します。
- Staging Release stage: Web App の Staging slot へデプロイします。
- Swap Staging to Production stage: staging slot と Production slot をスワップします。
テンプレート化
前回の YAML を適当にテンプレート化しましょう。今回は Jobs をテンプレート化と Job をテンプレート化を両方試したいので、テンプレート化する粒度は無駄に適当に作ってます。
まず、フォルダー構成を以下のようにしました。CI でフォルダー作ってその直下に webapp-pipeline.yml という雑な名前に YAML を作っています。これがパイプラインの起動時に呼ばれる YAML って想定で、各種のテンプレートたちを呼び出します。
テンプレートは、templates ってフォルダーにおいてます。
Test job のテンプレート化
やってることは、xUnit のプロジェクトを実行してるだけです。
Build と Test の Jobs をテンプレート化してもよいと思いますが、そうすると job のテンプレート化を試すタイミングを失うので、無駄に Build と分けてみました。
job をテンプレート化する場合は、stepsから書きます。パラメーターの呼び出し方が今までの書き方と異なる程度ですね。
あまり意識してなかったんですが、テストの実行コマンドにテスト結果を出力する argument がついてるんですね。
Azure Pipelines の実行ログで Tests タブをクリックすると内容を確認することができます。ここら辺の気遣いは素敵ですね。
Build job のテンプレート化
ASP.NET Core の Web アプリを Build→ zip 化 → してデプロイするための Artifact を publish という 3 step の構成にしています。
先ほど同様に job のテンプレートなので、steps から書きます。
パラメーターの呼び出し方と変数の呼び出し方が異なるので混乱しないように注意しましょうって感じです。
また、パラメーターは 3 行目のようにデフォルト値を定義したり、2 行目のように外から渡すために空にしておくって方法ができますので、用途に応じて使いましょう。
ここは、全体的によくあるサンプルのまんまの基本的な構成です。
Web App へのデプロイの jobs をテンプレート化
Web App へスロット指定でデプロイします。 先ほどとは異なり、jobs 自体をテンプレート化していますので、jobs から書きます。中身は前回とほぼ一緒です。
Web App の Slot のスワップの jobs をテンプレート化
ここも jobs のテンプレートなので、jobs から書いています。
前回のブログでは Azure CLI を叩いてるだけでしたが、Azure App Service Manage task の動作確認をしてみたかったのでコードを以下のようにしました。
パラメーターが少なくてわかりにくいなーと感じましたがドキュメントを見ての通り Production にリリースするなら簡単に書けるよう省略可能になってるんですねー初見はわかりにくかったけど楽に書けます。
パラメーター名を stagingSlotName って感じにしておけばよかったなー。
今回は試してないし詳しく見てもいないですが、先日のアップデートで Azure App Service now supports Swap with preview ってのも出てますね。
あとは、実行元の YAML を書いていきましょう。
起動用の YAML を編集
テンプレートを呼び出す YAML を書いていきましょう。ここでは主に以下のことをしています。
- トリガーの定義
- 変数の定義
- stage の構成
- テンプレートの呼び出しと、その際にパラメーターを渡す
- 実行の依存関係の定義
テンプレートの呼び出しは、このファイルから見た相対パスを書きます。（最初、プロジェクトのルートディレクトリからの相対パスを書いて file not found で死にました。）
前回からちょっと変えたのは、トリガーを master と develop ブランチにして staging のリリースまでは動くけど、production のリリースは、master ブランチじゃないと実行しないように制御しています（57-58行目）。
よくやりそうなのは「dev 環境にはリリースするけど、staging や production にはやらない」って感じだと思いますが、今回はただの検証で dev 環境用意してないのでこういう謎い構成になってます。環境増やすなんてテンプレート化しとけば簡単に増やせますしね♪
Azure Pipelines で実行ファイルを指定する
パイプラインの実行時、デフォルトでは azure-pipelines.yml が呼ばれるようになってますので、変更する必要があります。
Pipelines のメニューで変更するパイプラインをクリックします。
右上のメニューをクリック > Settings をクリックします。
YAML file path に今回作成した YAML のファイルパスを指定します。
ちなみにここでパイプラインを無効にしたりの操作もできます。
