Visual Studio Team Services CI/CDアドベントカレンダー：YAMLでビルド定義を書く(7日目)

はじめに

qiita.com

これはVisual Studio Team Servicesアドベントカレンダー7日目の記事です。今回はSprint 125で追加された新機能、YAMLビルドを紹介します。

個人的な不満

VSTSのGUIビルド定義は便利なのですが、ビルド定義を変更しても、作業項目が関連付けられないが不満でした。タスクにビルド/リリース定義を変更して、トラッキングしたいんですよね。一度フィードバックしたことはあるのですが、そのときも「要る派」と「別に要らないよ」派にわかれました。

今回追加されたYAMLであれば、YAMLファイルのコミット時に作業項目を関連付けられるので、ビルド定義の変更と作業のトラッキングができそうです。ではやってみましょう。

まだプレビュー機能なので、preview featureで有効にしてください。

YAMLでビルド定義を作成

現在のVSTSでは複数のレポジトリを対象にできないので、ビルド対象のレポジトリにYAMLファイルを作成します。

慣例的にymlという拡張子で、わかりやすい名前を指定します。

こんな風にもりもり書きます。YAMLの書式はWikipediaも参考にしてください。

YAML - Wikipedia

YAMLができたらビルド定義を作成します。

ビルド定義作成

ビルド定義作成からYAMLを選択してApplyをクリックします。

YAMLではまだVSTSとGitHubしかサポートされていないので注意してください。対象のソースレポジトリを選択します。

ProcessのYAML pathから対象レポジトリ内のYAMLファイルを指定します。

ビルド定義名と、Agent queueを選択します。実はAgent Queueに関してはYAML内に記述できます。

注意事項として、YAMLではほかのテンプレートのようにVariableが事前に定義されていないので、ASP.NET (Core)のビルドであれば、BuildConfigurationやBuildPlatformという値を定義しておかないと失敗します。

忘れやすいので注意してください。

ビルドを実行します。

こんな風にビルドが実行されます。

制限事項

docs.microsoft.com

YAMLビルド良さそうなのですが、現状ではまだまだ制限事項が多いです。

• VSTSとGitHubのみサポート
• TFVC未サポート
• ローカルテストできない
• ビルド結果のバッジが出ない
• Webインターフェースで一時停止ができない
• ビルド時に自動的に作業項目のリンクがされない(これは痛い)
• ビルド失敗時作業項目が作られない
• OAuth tokenが使えない
• ビルドジョブの認証が使えない
• Gitのサブモジュールなどが未対応

今後に期待。

YAML定義のカンニング

YAML定義一から覚えるのめんどくせーとは思います。そんなあなたのためにVSTSが教えてくれます。

一度GUIでビルド定義を作って、View YAMLをクリックします。

こんな風にできてます！ここからコピペすると、改行コードの都合で余計な改行が入ることがあるので、気を付けてください。

まとめ

YAMLビルドがGUIと同程度になれば、ビルド定義を完全にコードで管理することも、自動的に生成することもできるでしょう。今後が楽しみです。

Visual Studio Team Services CI/CDアドベントカレンダー：複数段階でビルドする(6日目)

はじめに

この記事はVisual Studio Team Services Advent Calendar 6日目の記事です。

qiita.com

VSTS/TFSでは、一つのビルドで、特定のリポジトリのソースをビルドする、ということが基本になっています。もちろん、複数のリポジトリを明示的にgit cloneもできますが、一つのリポジトリに複数の種類のソースが入っているとテンプレートでは難しいこともあります。

工夫すればいいのですが、はっきりと分離できなくて、どこまでがどのビルドかわかりづらい。そんな時に使えるのがマルチフェーズビルドです。

Sprint 123で提供が始まったばかりなので、正直今のままではまだ使いづらいのですが、将来機能強化されたらもうちょっと良くなると思います。

docs.microsoft.com

複数エージェントフェーズの作り方

簡単です。Processのところの ... をクリックして、"Add agent phase"を選択します。デフォルトではPhase 1が追加されています。

もう一つはデフォルトでagent phaseという名前になっていますが、わかりやすい名前に変えてください。エージェントフェーズで複数のビルドエージェントの最大数を指定することもできます。既定は無制限です。エージェントをあまり多く使いたくない場合、明示的に制限します。

ビルドタスクを追加します(略)。

今回は同じリポジトリに.NET Coreとデスクトップアプリソリューションが入っているとします。余談ですが、同じcsprojであってもdotnet coreビルドタスクではデスクトップ版のcsprojがビルドできないので、こういうのはやらないほうがいいです。もちろん、Visual Studioタスクでソリューションを指定すればいいのですが、ここは例ということで。

ビルドすると、Phase 1(.NET Core)とDesktop Phase(.NET Desktop)が別々のフェーズとしてビルドされています。ソースは最初にダウンロードしたものを共有するので、異なるフェーズで別々にダウンロードすることはありません。

また、ビルド単位が一つなので、artifactsも一つです。

エージェントを使わないビルドフェーズ

フェーズ追加するところにAdd agentless phaseというものがあります。これはビルドエージェントを呼び出さない(VSTS内部で実施してしまう)フェーズになります(たぶん)。

待ち時間やREST API呼び出しタスクがあるので、例えば、REST APIを呼び出して特定のサーバーに対してデプロイ前のビルド通知を行うとか、システム内で特定の設定を変更する、といったケースが考えられます…が、私がまだ理解できてないのか、このフェーズエラーになってしまいます。ドキュメントもまだない(リンク先はRelease機能用でした)ようで、ちょっと確認します。

将来の予定

複数段階のビルドができる、ということですぐに思いつくのはこの辺でしょう。

• 各フェーズを並列ビルドしたい
• 異なるリポジトリを一つのビルド定義で実施したい
• LinuxとWindowsのビルドをそれぞれ実行したい
• フェーズ単位でartifactを受け渡したい

…残念ながら現時点ではどれもできません。

docs.microsoft.com

• Ability to select a different queue in each phase.
• Ability to consume output variables from one phase in a subsequent phase.
• Ability to run phases in parallel. (For now, all the phases you define run sequentially).

将来作業予定のバックログに積まれているのはこの辺だそうです。この辺はいろいろフィードバックが上がっています。

今も頑張ればREST API使って、別のビルド定義呼び出すということはできるはずなので、しばらくはその辺でしのぐしかないでしょうかね。

将来が楽しみな機能の一つ、ということでマルチフェーズビルドの紹介でした。

Visual Studio Team Services CI/CDアドベントカレンダー : 複数環境へのリリース(5日目)

はじめに

この記事はVisual Studio Team Services Advent Calendar 5日目の記事です。

qiita.com

VSTSのリリース機能では複数の環境が作成できます。環境とは、リリースする対象の単位です。

• 検証、本番
• 複数のリージョン
• 複数のサーバーへの段階的な提供

3番目はWindows 10のInsider PreviewのようなFast, Slowといったように、一部の選考サーバーへ提供して、問題がなければ多くのサーバーへ提供する、というやり方です。こういうときに昨日紹介したリリースゲート機能が使えます。

複数環境の作成

Environmentsの中にあるAddをクリックして、New Environmentをクリックします。

新規追加するEnvironmentの名前をわかりやすいものにします。今回は検証環境を追加するということで、Stagingとします。

Moveをクリックすると、同じ階層で上か下かの選択ができます。これはあくまでも上下だけで、リリースの前後の順番指定ではありません。

Productionの後に挿入されたStagingをProductionの前に移動するには、Triggerを変更します。EnvironmentのProductionのTriggersからAfter Environmentを選択し、Stagingをチェックします。

こんな風に入れ替わりました。

並列インストール

複数の環境へ並列でインストールしたいという要件を満たす場合を考えます。

USのリージョンに展開するためのEnvironmentを追加します。どのEnvironment, Artifactsにも接続されていないEnvironmentはManual onlyのリリース状態です。

同様にTriggersを選択して、After EnvironmentでStagingを選択します。

このように視覚的に並列にリリースされる状態になっていることがわかります。

リリースの実行

リリースを実行してみましょう。ReleaseからCreate Releaseをクリックすると、リリース概要が表示されます。

この設定は、通常自動リリースになっている環境を明示的に手動に変更したいEnvironmentに対してチェックします。Createを実行すると、リリースが開始されます。

最初にStagingへのリリースが開始されます。

Stagingが終わったら、Productionの二つのEnvironmentへのリリースが開始されます。エージェントを二つ呼び出して並列展開が実行されます。

このようにリリースが成功したレポートが表示されます。

まとめ

リリース機能で並列、直列いろんな形のリリースができるようになります。昨日紹介したリリースゲート機能と組み合わせると順次展開できるので大変便利です。

Visual Studio Team Services CI/CDアドベントカレンダー：リリースゲート機能(4日目)

はじめに

この記事はVisual Studio Team Services Advent Calendar 4日目の記事です。

qiita.com

継続的デプロイメントはリリースする人が責任もって実施する前提ですが、お客さんが別途いる場合や、社内統制的にそうでもない場合があります。

そんな時に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が実装されました。

docs.microsoft.com

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で失敗したという状態になっています。

デプロイも実行されていません。

まとめ

今まではリリース前に承認可、拒否だけでしたが、リリース対象リソースの状態によってリリースを実行する、ということができるようになりました。

リリースタスクに含めなくていいので大変便利です。有効に使ってください。