はじめに
この記事はVisual Studio Team Services Advent Calendar 4日目の記事です。
継続的デプロイメントはリリースする人が責任もって実施する前提ですが、お客さんが別途いる場合や、社内統制的にそうでもない場合があります。
そんな時にReleaseで用意されているリリースゲート機能を使えばリリース手順そのものに手を入れることなく、解決できます。
リリース承認者を設定する
よくあるのがリリースを責任者(スクラムではPOでしょうか)が判定する、というケースです。
各Environmentの左側にあるアイコンをクリックすると、昨日紹介した、リリーストリガーの設定と同じ位置にUIがあります。特定のグループもしくはユーザーアカウントを指定できます。Timeoutは初期値で30日。
- Any order : いずれかの順番
- In sequence : 指定した順番
- Any one user : 何れか一人
1人だけ指定していると、その人が不在の場合長くリリースできなくなるので、複数指定しておきましょう。
承認者にはこのようなメールが届きます。View approvalをクリックすると、承認画面に移動します。
Approval(承認)か、Reject(拒否)します。Artifacts, Work Item, Testsなどを確認してます。
Approve(承認)、Reject(拒否)いずれでも理由を書いてください。そのあとリリースが実行されます。
リリースゲート
リリース時に特定の条件を満たしている場合のみ実行したい、ということはよくあります。今まではリリースタスクで書いていましたが、Sprint 126の新機能(現在プレビューです)でRelease Gateが実装されました。
Gatesをクリックすると、Azure Monitor, Azure Functions, REST API, Work Item Queryが選択できます。今回はAzure Functionを選択します。
今回は例なので、必ず失敗を返すAzure Functionを用意してみます。
FunctionsのUrlとKey、メソッド、Body、ヘッダーを指定します。Azure FunctionsのURLのクエリパラメータのCode=以下の部分を丸ごとKeyのところにコピーしてください。
URLには https://.../api/functionname だけを指定します。
リリースを実行します。
ゲート機能が有効なので、Functionsの事前検証に失敗します。
Logsをクリックすると、FunctionsがBad Requestで失敗したという状態になっています。
デプロイも実行されていません。
まとめ
今まではリリース前に承認可、拒否だけでしたが、リリース対象リソースの状態によってリリースを実行する、ということができるようになりました。
リリースタスクに含めなくていいので大変便利です。有効に使ってください。
