kkamegawa's weblog

Visual Studio,TFS,ALM関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

Visual Studio Team Services の Release Manegentの高度な設定(11日目)

昨日はRelease Managementによる継続的デプロイの基本を紹介しました。単にデプロイするだけであればビルド時に実行することもできますが、デプロイ時に他者の確認を要求したいことや、デプロイのメール通知といった機能を使うにはRelease Managementを使う必要があります。

そんな承認ワークフローの機能や高度な機能について解説します。

環境単位の承認設定をする

f:id:kkamegawa:20161210025431p:plain

デプロイ先は検証環境、本番環境といった複数の場所を用意できます。Environmentという名前で作成され、その環境ごとに独自のデプロイ用スクリプトが作成できます。

環境へのデプロイは複数の本番環境に対して並列で実行する、検証環境と本番環境であれば、検証環境のデプロイが成功してから本番環境へデプロイする、という設定に使用できます。

承認設定

f:id:kkamegawa:20161210205616p:plain

メニューのAssign Approversからリリース前の承認者を指定できます。一人だけ指定していますが、一人だけだと休暇などで不在の場合リリースが止まったままになるので、複数人もしくはグループを指定します。

誰か一人が承認する、だれか一人が承認するといった挙動の選択ができます。リリース後も同様に承認者を指定できます。

リリース用の環境設定

f:id:kkamegawa:20161210205617p:plain

サーバーにアクセスするためのパスワードやユーザ名をスクリプトに直書きすると、本番と検証でスクリプトを書き分けるといった必要があります。

ここで定義しておけば、スクリプト中ではこの変数(ビルドと同じです)を参照すれば環境ごとにスクリプトを分ける必要もないので、便利です。

デプロイ条件

f:id:kkamegawa:20161210205618p:plain

デプロイタイミングをいつ実行するかという指定です。Release Managementでは「リリースを作成」してからデプロイを実行するという動作になっています。作成されたリリースをいつ実行するかという設定です。

自動的に実行する、指定時間に実行するという設定が選択できます。例えば、リリースは定時間内に行い、問題なければ0:00にデプロイを開始するという設定ができます。

通知指定

f:id:kkamegawa:20161210205620p:plain

リリースのメール通知をするかどうかという指定です。リリースされたとき、失敗した時だけという指定ができます。メール配信先は個人ごとのプロファイルで設定します。

f:id:kkamegawa:20161210205632p:plain

リリースが作成され、承認依頼があるとこのように通知されます。クリックすると、理由を書いて、承認するか却下するか選択します。

f:id:kkamegawa:20161210205628p:plain

メール通知はこのような形で送られます。承認依頼のメールも同様です。

実行エージェント

エージェント選択

f:id:kkamegawa:20161210205631p:plain

Run to agentをクリックすると、実行エージェントの選択ができます。ビルドと同様にHostedや、オンプレミスのエージェントを指定できます。

Run on Server

f:id:kkamegawa:20161210205621p:plain

Add taskをクリックするとビルドと違い、Add a server phaseという指定があります。

f:id:kkamegawa:20161210205622p:plain

Server phaseを指定すると、一つだけ選択できます。これは手動介入タスク、つまり一時停止です。

f:id:kkamegawa:20161210205623p:plain

追加するとこのようになります。具体的な用途としてはデプロイ前にサーバーの特定の状態(例えばファイル配置や、別のタスクで実行されているサーバーへのデプロイなど)を人間の目で確認するために用意されています。なので、使うときは気を付けてください。

リリースの高度な設定

Trigger

f:id:kkamegawa:20161210205625p:plain

昨日までの状態では、リリースは手動で作成しなければなりませんでしたが、Continuous Deploymentをチェックすると、ビルドでartifactが作成されると(つまりビルドが成功すると)、自動的にリリースを作成します。

Scheduledをチェックするとスケジュールに従って作成します。approversのところにもスケジュールがありますが、別の指定になるので注意してください。どちらかのみを使うといいでしょう。

リリース番号

f:id:kkamegawa:20161210205626p:plain

リリースには番号を付けられます。標準で通し番号ですが、独自の番号を使いたい場合はここで指定します。

保存期間

f:id:kkamegawa:20161210205627p:plain

リリースを何日間保存しておくかという設定です。ビルドがあるので、こちらは短めでもいいでしょう。

リリース作成後の情報

関連作業項目

f:id:kkamegawa:20161210205630p:plain

リリース作成後、関連する作業項目の確認ができます。

関連コミット内容

f:id:kkamegawa:20161210205629p:plain

同様に変更されたファイルの内容確認ができます。

Library

f:id:kkamegawa:20161210205624p:plain

リリースタスク中に使う値をひとまとめに管理するLibraryという機能です。これいつ追加されたんでしょ…知らなかった。

Add variable groupをクリックすると開始します。

f:id:kkamegawa:20161210205615p:plain

大太陽とは想像できますけど、まだ使ったことないので、解説はこの辺で。

まとめ

継続的デプロイのための高度な設定を紹介しました。パスワードを隠すための値の設定や、リリースを別の人に任せているけど、いつリリースされたか、ほんとにリリースされたか通知がほしい、というようなケースで非常に便利だと思います。

エージェントの時間はビルドと共通になるので、気を付けてください。

明日はパッケージマネージャを紹介します。