はじめに
この記事はVisual Studio Team Services Advent Calendar 2日目の記事です。
今日は昨日説明しきれなかったビルド定義の高度な設定について解説します。特に設定しなくても構いませんが、大規模環境になると、考えたほうがいいでしょう。
Options(その他)タブ
ビルド定義のOptionsタブでは以下の設定ができます。
Description
ビルド定義の説明を追記します。
Build number format
ビルドを行うたびに一位に識別するIDが作成されます。その時のフォーマットを指定します。詳細はこちらで解説されています。大規模環境で特定の名前を付けたい場合使ってください。
Badge enabled
GitHubなどで表示されるビルドが成功したか失敗したかというバッジのURLです。HTMLに書けばこんな風に表示されます。
これは石川さんのLambdicSQL.SQLServerのレポジトリですが、私のVSTSで毎日定期的にビルドしています。CIが成功したらこんな風にsucceededの画像が表示されます。
New build request processing
ビルドの実行キューの状態を制御します。
- Enabled : 有効
- Paused : ビルドを一時停止します。
- Disabled : ビルド定義を無効にします。
Pausedはエージェントプール内のビルドサーバーをメンテナンスしたいとき、「キューには入れるけど、ちょっと待たせる」という状態にできます。この場合、ビルドキューのタイムアウトは起きません。比較的最近入った新機能です。
Automatically link new work in this build
ビルドが成功したとき、自動的に作業項目を関連付けます。
こんな感じですね。ビルド結果と作業がわかりやすくなります。
Only link to work added to specific branched
特定のブランチに関連づいているときだけ作業項目をリンクさせます。特に変える必要はないでしょう。
Build job - Build job authorization scope
ビルドジョブをどの範囲で認証するかということです。
- Project Collection : プロジェクトコレクション単位…ですが、VSTSは一つしかサポートしていないので、事実上全体ですね。
- Current Project : チームプロジェクト単位です
ビルドジョブが複数のチームプロジェクトにアクセスする必要がある場合、Project Collectionを選んでください。初期値なので、セキュリティ上の事情などで、明示的にアクセスさせたくない場合を除いて、そのままで構いません。
Retention(ビルド結果の保存)
VSTSでは、ビルドが終わると内蔵ストレージに一定期間保存されます。その期間を指定するのがRetentionという設定です。初期状態では成功したビルドを一つ、10日間保存します。これはブランチ単位で設定できます。
いわゆるリリース失敗による切り戻しを考えると10日間あれば十分でしょう。ここではビルド定義単位の作成です。
ビルド定義の履歴参照
ビルド定義はVSTS内ではJSON形式で保持されています。ということは履歴の差分比較もできます。
Historyから任意の二点を選択します。
右クリックして、Compare Differencesを選択します。
VSの差分比較のように、追加された箇所は緑、削除されたところは赤になります。ただ、JSONでなおかつ、タスクごとにしか見ていないようで、ビルドタスクの順番を変えたり、追加したりすると、思っていたのと違う結果になりそうです。
一つ前のビルド結果と見比べるのが現実的な使い方だと思います。
ビルド定義のセキュリティ
三点リーダのところをクリックすると、Securityという項目があります。
ビルド定義のセキュリティが設定できます。実はビルド定義が作成できるのはBuild Administratorグループに属していないといけません。チームプロジェクトを作ったユーザーは通常入っています。
しかし、チームの開発メンバーとして追加すると、Contributorに所属することになります。Contributorにはビルド定義を作成する権限がありません。
Build Administratorに追加するには歯車アイコンから、Securityを選びます。すると、チームプロジェクト既定のグループが表示されますので、その中からビルド定義を作っても良い人をBuild Administratorsに追加してください。
Azureと一緒に使う場合、ビルド定義はAzureサブスクリプションにアクセスすることもあるため、Azure側の権限も忘れないでください。
MSアカウントで運用していると、正直この辺は結構大変なので、組織でVSTSを使う場合、MSアカウントではなく、Azure ADベースの組織アカウントで運用することを強く勧めます。
組織アカウントであれば、当然Azure ADのセキュリティグループとも連動するので、サブスクリプションの権限割り当てとかどっちがどうだったかとか考える必要も無くなります。
まとめ
セキュリティの設定やRetentionの設定は気づかないと「あの時のビルド結果の成果物どうしたっけ」となりがちです。今後Releaseの機能を使う時、Retention Policyを設定したり、恒久的に維持するということも可能になっていますがその辺りはべっとCDの説明するときに解説します。
