ちょっと遅くなりました。明日も遅くなるかもしれません。昨日はVSTSで簡単にビルドキューに挿入するところまでを紹介しました。今日は使うと便利なビルドオプションを紹介します。
ビルドの細かい設定
ビルドオプション
ビルド時のOptions, Repository…などをクリックすると、それぞれ高度なせっていが行えます。Optionでは以下の三点が指定できます。
- Multi-configuration:複数のビルド構成のビルドをサポートします。例えば、Debug,Release。Windowsネイティブアプリケーションであれば、x86,x64といった構成のビルドを一度に(キューの並列度に応じて)ビルドします。
- Create Work item on Failure:ビルドが失敗したとき、自動的にWork Itemに登録します。普通の作業ブランチであればいいのですが、masterとかリリース用のブランチのビルドが失敗した場合は登録したほうがいいでしょう。
- Allow Scripts to Access OAuth Token:独自のビルドスクリプトでビルドサーバーが持っている権限を使いたい場合にここにチェックします。システム権限で動くので、ビルド中にVSTS内の機能にアクセスできるようです。
リポジトリオプションを設定する
どのTFVCもしくはGitリポジトリをビルドするかを指定します。TFVCはチームプロジェクトに1つしか持てませんが、Gitは複数のリポジトリがあるため選択してください。ブランチの指定も可能です。
- Checkout Submodule:Gitのサブモジュールを同時にチェックアウトするときは使います。
- Don't sync sources:ソースの同期を行いません。なんだそれ？と思うかもしれませんが、独自のビルドスクリプト内でGitのfetchを自分の管理で行いたいときに便利です。
- Shallow fetch:Gitのコマンドでいうところの"git fetch --depth=n"です。余りに履歴が大きいとfetchするのも時間がかかるので、ある程度短くしたい場合に便利です。
独自の値を設定する
ビルドバージョン番号は既定で決まっていますが、独自の値を設定したいとか、ビルドスクリプト内で特殊な処理を行いたいという場合、ここに値を指定します。
私の場合はNuGetパッケージをローカルで作るときにビルド番号を足しています。定義済みの値もあるので、こちらを見てください。
ビルドトリガー
いよいよCIらしい設定のビルドトリガーです。何も設定しなければ明示的にビルドをNew Queue Buildクリックするしかないのですが、Continuous Integrationをチェックするとチェックイン/コミットごとにビルドが実行されます。
どこにコミットしてもビルドが実行されると困るという場合は、パスもしくはブランチでフィルタしましょう。
Scheduleにチェックすると、指定した曜日の指定した時間(タイムゾーンを考慮します)にビルドが行われます。長いことこの設定していたの忘れてて、なんで毎日ビルドされているんだろうと気付きませんでした…。
一般オプション
- Default agent queue:ビルドを実行するビルドキューの規定値他を指定します。既定ではHostedですが、特定のキューで実行したい場合、ここで指定します。
- Build Job authentication scope:ビルドジョブの認証範囲をプロジェクトのみにするか、全プロジェクトにするかという指定です。既定の全プロジェクトのままでもいいでしょう。
- Badge URL:GitHubなどに表示されているビルドが成功したかどうかのステータスを表示するURLが取得できます。
- demands:この機能が入っていないビルドエージェントではビルドしない、という設定です。例えば、必ずLinuxもしくはmacOSで動かしたいならば、nameにsh、typeにexistsを指定すればOKです。ビルドエージェントがアクセスできる環境変数を基準にして判定しています。
ビルド保持期間
ビルド結果を既定で何日間保持するかという設定です。短くしてもいいですが、VSTSの場合短くしてもどうにかなるという話は聞いたことがないので、特に変える必要はないでしょう。リリースの都合で少し長く伸ばしたいという場合は長めのルールを"Add new rule"で追加してください。
ビルドエージェントキュー
ここでは各ビルドエージェントにどんなソフトがインストールされているのか(どんな機能があるのか)確認できます。HostedのAgent.Versionとか、antのバージョンもわかります。
通常、例えばXamarinや.NET Coreがリリースされてもすぐに反映されません。スプリントが三週間単位なので、三週間のうちにリリースされたものはおおむね次のスプリントで入るようです。急いで検証しなければならないという場合はローカルエージェントを使ってください。
ビルド結果
ビルドが完了すると、トップページでどんなビルドが過去何回成功(失敗)したか一覧で表示されます。Mineが自分のビルドです。今一度しかビルド指定なので、100%となっています。
ビルド定義の…をクリックすると、各種メニューが表示されます。複雑なビルド定義を作った場合、テンプレートにして保存しておくのもいいでしょう。
ビルドの詳細な情報です。passingというのは次の継続的デリバリーようにartifactsが用意できている、ということになります。ほかにもいくつかのステータスがあります。
タスクのグループ化
ビルド定義の一部をグループ化して、ほかのビルド定義でも再利用しやすくすることができます。グループ化したいビルドタスクを1つ以上選んで、右クリックするとメニューが表示されます。Create task groupをクリックします。
グループ名と、カテゴリー、パラメータを指定してCreateをクリックします。
すると、選択したタスクがTask groupとして登録されます。
Task Groupsをクリックすると、グループ化したタスクが登録されています。
各タスクの設定もそのままコピーされています。ある程度以上大きいビルド定義で特定の処理をグループ化しておけばほかの人も使いやすくなります。
おまけ：XAMLビルド
Visual Studio 2005からずっと主役だった以前のビルドシステム(XAMLビルド)はまだ使えます。Visual Studioから「XAMLのビルド定義」をクリックすると…。
こんな風にエラーになりますｗ。XAMLビルドはビルドコントローラーをつなぐ必要があります。VSTSはこのビルドコントローラーを持たないので、オンプレミス側に構築してください。でも、XAMLビルドはもうディスコンになることが決まっているので、今から投資しないほうがいいでしょう。
まとめ
ビルド定義の細かい設定を紹介しました。CIだけならContinuous Integrationにチェックするだけですが、最初は試行錯誤することもありますから、最初からCIは設定せず、うまくいき始めてからCIを設定しても問題はありません。
明日はContinuous DeliveryをサポートするRelease Management(RM)を紹介します。両方紹介してからスケールアウトビルドパイプラインを紹介します。
