kkamegawa's weblog

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

Visual Studio Team Services CI/CDアドベントカレンダー:ビルド定義作成(1日目)

はじめに

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

qiita.com

今年もひとりアドベントカレンダーをやってみようと思います。去年はVSTSの全機能を紹介するという方針でやっていましたが、今年はVSTSのCI/CDに絞ってやってみようかなと思います。基本的にはTFS2018でも同じ機能が実装されているので、参考にしてください。

全日程やるつもりですが、飛んでしまったらまぁその時はその時で。

チームを作る

チームを作るには去年のこちらの投稿を見てください。

kkamegawa.hatenablog.jp

ソースコードコミット

f:id:kkamegawa:20171130044631p:plain

もちろんビルド定義を作る前にはコードをコミットしておきます。1つ注意点として、ビルドにシェルスクリプトやバッチファイル、PowerShellスクリプトを使う場合、あらかじめコミットしておいてください。

ビルド定義から参照できるのはレポジトリの内部だけなので、レポジトリにないファイルはビルド定義内のタスクでは参照できません。

ビルド定義を作る

自動ビルドをするには、VSTSでビルド定義を作ります。Visual Studioのソリューションを使う場合、Visual Studioでビルドできるようにしておいてください。

f:id:kkamegawa:20171130044618p:plain

VSTSでビルドするにはBuild and ReleaseからBuildsをクリックして、定義の作成を開始します。基本はGUIですが、最新機能(Sprint 125)でYAMLによるビルド定義を書けるようになりました。これは別途紹介します。

ここではASP.NET Coreのビルド定義を紹介します。

プロセス全体の定義(Processes)

f:id:kkamegawa:20171130044619p:plain

VSTSのビルドではProcessでビルドプロセス全体にわたる共通のパラメータを定義します。これはビルド定義にて指定するパラメータのうち、「みんな共通で使うよね」という項目を一か所で定義すればあとは自動的に参照するという仕組みです。

それぞれのパラメータにある、unlink allをクリックすると、各ビルドタスクにリンクされている設定(キャプチャ画面ではcsprojのminmatchパターン)が削除されて、個別にcsprojファイルを指定できるようになります。

ビルドに必要なソリューションファイル名とかタスクごとで変わることはないため、ここで定義します。この設定は各ビルドタスクで定義されるため、ユーザーが意識する必要はありません。言い換えれば、このParametersにある設定だけ指定しておけば割と大丈夫です。

ソースコードレポジトリの指定

f:id:kkamegawa:20171130044621p:plain

VSTS本体のTFVC(Subversionっぽいやつ)、GitのほかにGitHub、BitBucket、外部のGit、Subversionが選択できます。

GitHubの場合は自分がContributorのレポジトリのみ指定可能です。さらに、コミット時やPR時に自動ビルドをしようとすると、自分がOwnerでなくてはならないので、注意してください。これはまた日を改めて紹介します。

cleanはビルド前にエージェントをきれいにするか。VSTS内蔵のエージェントを使う場合は常時クリーンなので、指定しなくてもいいです。自分で用意するプライベートエージェントの場合のみです。

Gitの場合はブランチや、Git-LFSを使うか、Sharow fetchするかといった指定もあります。この辺はGitの説明を読んでください。

ビルドキューの指定

VSTSはエージェントプールという単位でビルドエージェントを管理しています。

docs.microsoft.com

f:id:kkamegawa:20171130044620p:plain

一つのプールに複数のエージェントがぶら下がっていて、各ビルド定義はいずれかのエージェントプールを指定します。エージェントプールに登録されている、あいているビルドマシンをVSTSが自動的に呼び出します。

並列度はライセンスによって縛られています。VS Enterpriseサブスクリプションを持っていればその分増えます。

Hosted~で始まるエージェントプールはVSTS内蔵の(用意されている)ビルドエージェントです。

  • Hosted : Visual Studio 2015用だと思ってください
  • Hosted VS2017 : Visual Studio 2017がインストールされているビルドエージェントです。
  • Hosted Linux Preview : Linuxで動いているビルドエージェントです。Dockerコンテナーで動いています。
  • Hosted macOS Preview : macOSで動いているビルドエージェントです。

インストールされるソフトは定期的にメンテナンスされており、大体三週間に一度のVSTSの機能強化と並行して実施されているようです。

docs.microsoft.com

何がインストールされているかはこちらからみてください。ソフトによってはビルド時に追加もできます。調べ方や、ビルドエージェントがどうやって判定しているかは別途書きます。

Task (ビルド順序)

f:id:kkamegawa:20171130044622p:plain

次は実際にビルドを行うためのビルドタスクをGUIで登録します。最初の画面でemptyを選ぶと自分で一から1つずつ追加する必要がありますが、ASP.NET Coreのテンプレートを選んだので、最低限のものは登録されています。

注意点として、最後にあるPublish Artifactsタスクは基本的に追加することを強く推奨します。この辺りのビルドエージェント内での動作に関しては、別途紹介します。

Variable(ビルド定義内で使う値)

f:id:kkamegawa:20171130044623p:plain

VSTSのビルド定義内に出てくる$(variable)という見慣れない値はVSTSのエージェントで設定されている値のほかに、Variablesタブで指定できます。

docs.microsoft.com

VSTSビルドエージェント内で決まっている値に関してはこちらを見てください。これらの値はバッチファイルやシェルスクリプト、PowerShellスクリプト内からでも参照できます。

例えば、VariableにMyVariableを登録して、ビルドタスク内で$(MyVariable)と指定すればビルド時に自動的に置換されます。

典型的な例ではデータベースのパスワードなどを格納します。しかし、ほかのユーザーが削除して、別の値を設定することもできてしまうので、より機密性の高い値を使う場合、Azure KeyVaultの使用をお勧めします。

KeyVaultを使う方法は別途書きます。

Trigger(自動ビルド設定)

f:id:kkamegawa:20171130044624p:plain

ビルドがいつ動くか、という設定です。Trigger StatusをEnabledにすると、なんらかのトリガーでビルドが自動的に実行されます。

下にあるRepositoriesは、リポジトリ内の特定のパス(既定は全体)にファイルがコミットされたときにビルドが実行される、という設定です。

右側のペインは特定の日付及び時間が来るとビルドが実行されます。もちろん該当ビルドキューから呼び出されるビルドエージェントは起動しておきましょう。

もうちょっとありますが、長くなるのと、とりあえず実行には問題ないので、後日紹介します。

ビルド実行

f:id:kkamegawa:20171130044627p:plain

ビルドができたら、Save queueをクリックするとビルドが実行されます。ここではLinux エージェントを指定して、います。Variableの中には実行時オンデマンドで指定可能なパラメータもありますので、最後にこの画面で変更できます。

ビルド中ログ

f:id:kkamegawa:20171130044628p:plain

ビルド中はこんな感じでログが出力されます。削除される前であれば、いつでも見ることもできます。

終了

f:id:kkamegawa:20171130044630p:plain

ビルドが終了すると、ログ、実行した単体テスト、コードカバレッジ(プロジェクトによる)、データベースの差分(Redgate使った場合)が表示されます。

ビルド結果概要

f:id:kkamegawa:20171130215406p:plain

Summaryをクリックすると、VSTS内に残っているビルド結果の履歴が参照できます。ちょっと試行錯誤しすぎて、エラーが山盛りです…。

明日は必須ではないけど、設定したほうがいい高度なビルド機能について紹介します。