kkamegawa's weblog

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

Visual Studio Team Services CI/CDアドベントカレンダー:Inside Build Agent(14日目)

はじめに

これはVisual Studio Team Servicesアドベントカレンダー14日目の記事です。

qiita.com

VSTSにはCircleCIやAppVeypor、Travis CI、Bambooのようなクラウドベースのビルドサービスがあります。240分/月までは無料です。ただ、テンプレートから作ったものをビルドするだけでも3-4分かかるものもあるので、無料枠はどんな感じで使えるのかという感じをつかむくらいでしょうか。

そんなVSTSのビルドエージェントですが、実は自分でたてることもできます。インストールしてどんな挙動になっているのかとか、ちょっとしたTIPSを紹介します。

VSTSエージェントのソース

github.com

VSTSは.NET Core上で動いています。なので、Windows以外にもmacOS, Linuxもサポートしています。Linuxは特にdockerイメージも公開されているので、インストールは楽です。Windows版のDockerイメージも公開してほしいみたいなフィードバックは出ているのですが、まだないようです。

Docker使う方法は以前書いたので、こちらを見てください。

kkamegawa.hatenablog.jp

DockerイメージにはVSTSで動いているソフトと同じものが入っているので、それ以外で必要なものを追加する場合は自分でdockerイメージをビルドします。node.jsや新しいJDKであればビルドタスクで追加もできるので、dockerビルドする必要はありません。

ローカルか、プライベートか。

VSTSが提供するエージェントの場合、ローカルディスクが10GBまでという制限があります(緩和してほしいというリクエストは出ています)。これを超えるとpullやビルドに失敗するので、ゲームなどで大きなコンテンツをビルドするときはレポジトリをわけるか、ローカルエージェントを使うしかありません。

後はCPUが2コアだったはずなので、大きいソリューションを並列ビルド、テストしたいときもちょっと困りますね。

そのほか、新しいXCodeをいち早く使いたいとか、ライセンス上nuget等でとってこれないライブラリをビルドするときもプライベートエージェントを使ってください。

エージェントのフォルダー構成

ビルドエージェントのフォルダー構成はこのような感じです。

f:id:kkamegawa:20171214054159p:plain

_work(インストール時に変更できます)というフォルダの下に1,2,3...と数字が振られます。これがビルド毎に使われる作業フォルダです。

  • a : artifact(成果物)が格納されます。publish to artifactsタスクがこのフォルダーを丸ごとVSTSにアップロードします。
  • b : ビルドで一時的に使います。
  • s : ソースを取得するフォルダーです。

これらのフォルダーの絶対パスを取得したい場合、VSTSのビルドエージェントの定義済みの値を使用します。

docs.microsoft.com

ビルドタスクのPowerShell, バッチファイル、シェルスクリプトで参照できます。

f:id:kkamegawa:20171214054158p:plain

こちらはDeployment Group用に構成したエージェントです。_workというフォルダーの下にr1というフォルダーができており、その配下はビルドと同じ構成になってます。

aというフォルダの下にビルド定義で生成された成果物(artifact)がダウンロードされていることが分かります。ビルド定義でdropフォルダの下に生成すると指定しているのが分かると思います。

ビルドエージェントの更新

ビルドエージェントはGitHubのReleaseからダウンロードします。一部の環境でGitHubのRelease(というよりAWSのS3)へのアクセスが制限されている場合、VSTSの機能での更新はできないので気を付けてください。

Dockerみたいにmicrosoft.comドメインから配布してくれるとありがたいんですが…(フィードバックしたんですが)。

docs.microsoft.com

そのほかの展開についてはこちらをみてください。ちなみに、VSTSへの接続は一台のビルドサーバーが一つのVSTSへの接続しかできない、ということはありません。リソースが許す限りいくつでもサービスを構築できます(もちろんインストール用のフォルダは別の名前にします)。

PATでの接続になりますが、PATの期限切れの通知はないので気を付けてください。

capability(ビルドエージェントで使用可能な機能)

VSTSでビルドエージェントと一口に言っても何がビルドできるのかわかりづらいでしょう。何がインストールされているかということはAgent Queueハブから対象のビルドエージェントを選択すると、Capabilityという項目でわかります。

f:id:kkamegawa:20171214054200p:plain

例えばこれはVSTS AgentのLinux Dockerイメージの場合です。JDK7/8はじめいろいろ入っています。独自のDockerイメージを作るのもいいでしょう。

f:id:kkamegawa:20171214054201p:plain

Hosted VS2017イメージです。実は作成方法はこちらのGitHubで公開されています。

github.com

このスクリプトを使えば理論上同じ機能を持つプライベートエージェントが作成できます。VSTSのHost agentはまだWindows Server 2012 R2のはずなので(そのうち2016になるようです)、Windows 10でなければビルドできないようなもの、例えばMixed Reality対応アプリやUnityに関しては残念ながらローカルエージェントを使ってください。

macOSのXCodeも新しいものにリアルタイムでついていきたい場合は自前で管理するしかないようです。

f:id:kkamegawa:20171214054203p:plain

capabilityはエージェントの環境変数の値がそのまま出ていますが、実は自分でも特殊な値を追加できます。自分のローカルエージェント(default)のUbuntu001のcapabilityから"Add capability"で好きな値(ここではmycapabilities)を指定します。

f:id:kkamegawa:20171214054204p:plain

そして、ビルド定義のDemandsにmycapabilitiesがなくてはならない(exits)と指定します。

f:id:kkamegawa:20171214054205p:plain

仮に、VS2017エージェントプールを指定しても…。

f:id:kkamegawa:20171214054206p:plain

このようにHosted VS2017のエージェントにはmycapabilitiesがないので、ビルドに失敗します。

これは自分で指定した追加capabilityですが、そもそもVisual Studioが必要なのに入っていないエージェントプールを指定しても同じエラーになります。

※:確か以前はキューに投入する前にDemandsと一致していないよという警告が出たはずなんですが…。

TIPS

自分で管理しているとはいえ、ソースの中に機微情報が入っているなどの理由でビルドエージェント内にファイルを残しておきたくない場合があります。

ビルドエージェント2.126(最新版)の新機能に、ビルド終了時pullしたソースコードを消してくれる、という機能が追加されました。

ビルド定義のvariableに"process.clean"を追加して、trueを指定してください。ビルド終了時にローカルのソースファイルが自動的に削除されます。

ビルドエージェントはあまり知られてないことも多いですが、ビルドタスクともどもオープンソースなので、困ったらソース見るといいと思います!