Visual Studio Team Services CI/CDアドベントカレンダー：NuGetパッケージのCIとパッケージ機能(18日目)

はじめに

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

qiita.com

VSTSにはNuGet/maven/npmパッケージソース機能が用意されています。大部分の用途ではパブリックな公式サイトから取ってくればいいのですが、特定のバージョンのまま検証が済むまでアップデートをさせたくない、というケースはあり得ます。

オンプレミスのTFSを使う場合、インターネットへの接続を(今時ではちょっと難しくなりましたが)抑止したい場合にもパッケージサーバー機能は有効です。

なお、パッケージ機能に関しては、BASICライセンスでは使えません。有償ライセンスを買うか、VS Enterpriseサブスクリプションを購入する必要があります。

当然継続的インテグレーションも可能になっています。使い方を紹介します。

パッケージフィードを作る

まずはパッケージフィードを作らなくては話になりません。Packagesから作成します。ここではすでに作っているので、New feedをクリックします。

わかりやすいフィード名を追加します。

プライベートか、VSTSアカウントが使える人なら誰でも使えるようにするのかという設定、Upstream(nuget.orgやnpm.org,mavenなど)をソースにするのか、ここに登録したパッケージのみ使えるようにするのか、といった設定を行います。

フィード作成直後は当然ですが何もありません。ここから作っていきます。Connect to feedをクリックすると、この作成したフィードに接続するための情報が表示されます。

フィードには正式版以外にもプレリリース(nugetであれば-preオプション必須のパッケージ)版のパッケージなどを設定できます。

nuget/maven/npm/gradleといったパッケージのソースとして使うこともできます。

コマンドでVisual Studioのパッケージソースとして追加できます。表示されているコマンドをそのままコピペして、実行します。

正常に追加されると、Visual Studioのnugetパッケージマネージャーのソースとして追加されているのがわかります。

nugetパッケージのCI

これでどハマりしました。久しぶりで、その上以前使っていたタスクが非推奨になっていたので、一からやり直しの上に、.NET Coreにも罠が待っていました…。そのうち改善されるとは思います。

今回は.NET Coreのライブラリをnugetパッケージにするためのビルド定義を作ります。通常の.NET Coreテンプレートからで構いません。

NuGetのバグ回避のため、最新版をスタンドアロンインストールするタスクを追加しておきます。本来は.NET Core SDKでもnupkg作れるようですが、nugetを使います。

現在のHosted VS2017 agentに入っているnugetでは.NET Coreのnugetパッケージが作れないという既知のバグがあります。ちょっとダサいですが、hosted agentのmsbuildをフルパスで呼び出して以下のタスクを実行します。

msbuild.exe /t:pack /p:Configuration=$(BuildConfiguration)

ビルドしたnupkgファイルをartifactstagingフォルダにコピーします。

nuget pushコマンドで作成したVSTSローカルのパッケージフィードに登録します。

これでビルドすると、先ほど作ったパッケージフィードに登録されています。ここではやっていませんが、ビルドごとにパッケージバージョンののインクリメントを実行することもできます。

クロスプラットフォーム対応nupkgの生成

.NET Coreの場合、macOS/Windows/Linuxと複数プラットフォームのバイナリが入ったnupkgを要求されることがあると思います。そういう場合、以下の方法で実施できるでしょう。

• Hosted VS2017/Hosted Linux/Hosted macOSそれぞれのエージェントでマルチフェーズビルドを実施する
• ただし、それぞれのフェーズではnupkgを作らず、生成されたdllのみをartifactとして登録する。
• Release 定義でartifactを取得して、nupkgを生成する

それぞれのhosted agentでは当然サーバーが違うので、複数フェーズビルドでは最後にnupkgをまとめることはできませんが、artifactとして一つにまとめることはできるので、バイナリのみ集めておいて、Releaseでnupkgを作ればいいでしょう。

パブリックとプライベートの使い分け

通常、stableのリリース版はnugetやnpmに発行すればいいですが、内部のプレリリース開発用までnugetに出していると煩雑です。そういう場合のために、外部に公開する前にVSTSのnugetサーバー機能を使って評価すればいいでしょう。

個人的にはdevブランチをビルドするとVSTSのPackageへデプロイ、masterブランチをビルドするとnugetへ登録するというビルド定義を作っています。

おまけ

このビルドがやたら時間がかかってしまい(Windows のビルドエージェントがいつもより遅かった気がする)、ビルドの無償枠がだいぶ溶けました…。

Visual Studio Team Services CI/CDアドベントカレンダー：ビルドタスクの実行条件を指定する(17日目)

はじめに

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

qiita.com

ビルドタスクを定義してもちょっと特定の時は動いてほしくない、という場合はあります。例えば、masterブランチのビルドをCIで実施するけど、手動で実行したときはテストしたくない、というケースはありえます。

そんなときのために、ある条件を満たすと特定のビルドステップを実行しない、という機能がありますので、紹介します。

ビルド定義での条件設定

ビルドタスクの実行条件はControl Optionsをクリックして展開される、Runt this taskで設定します。標準でCustom conditionsが選択されていますが、他の物を指定することもできます。

• Only when all previous tasks have succeeded
• Even if a previous task has failed, unless the build was canceled
• Even if a previous task has failed, even if the build was canceled
• Only when a previous task has failed
• Custom conditions

それぞれ順に以下の意味になっています。

• 前のタスクが成功した時だけ実行する
• 前のタスクが失敗した時、ビルドがキャンセルされてない限り実行する
• 前のタスクが失敗した時、ビルドがキャンセルされた場合でも実行する
• 前のタスクが失敗した場合のみ
• 独自の条件を指定する

2-4番目に関しては、ビルドが失敗したとき、何らかのクリーンアップを実行するといった場合に指定するといいと思います。

本記事ではちょっとわかりにくい5番目のCustom Conditionsについて解説します。

Custom Conditionの設定

例えば、このビルド定義にはmasterへのコミットでビルドを実行する設定になっています。CIがかかったときはテストタスクを実行してほしいけど、手動で実行したときはテストをしなくてもいい、という条件を設定します。

and(succeeded(), in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI'))

保存して、手動でQueue Buildをクリックします。

VsTest - testAssembliesタスクにチェックが入っておらず、実行されていないことが分かります。

masterにコミットしたときに実行されるCIではVsTest - testAssembliesにチェックが入っていて、実行されていることが分かります。

Custom Conditionsの式は以下の形式です。

論理式(判定結果, 論理式())

論理式にはand, orなどが指定できます。variablesと比較する場合、variables['値']で実行時の値と比較可能です。

docs.microsoft.com

なお、この条件は以下のように重ねることができます。

and(and(success(),...)

参考文献

公式ドキュメントはこちらにあります docs.microsoft.com

Visual Studio Team Services CI/CDアドベントカレンダー：外部レポジトリ(GitHub)をビルドする(16日目)

はじめに

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

qiita.com

今までVSTSの内部レポジトリのビルドについて紹介していましたが、今日は外部のレポジトリ具体的にはGitHubのビルドについて紹介します。

VSTSはオールインワンでそろっていますが、外部サービスとも連携します。VSTSもよくはなっていますが、VSTSはクローズのみなので、オープンソースの開発をするならGitHubということは多いと思います。この記事ではVSTSのビルドサービスをGitHubのレポジトリに対して実行する方法について紹介します。

前提条件

以前も書きましたが、GitHubのレポジトリをビルドする場合、ビルド定義を作る人がownerになっている必要があります。Contributorではコミット時のビルドの設定ができないので、注意してください。スケジュールビルドはできます。

GitHubへの認証を設定します。OAuthかPATを使うかお好みで。

対象のレポジトリを選択します。ちょうど先日GitHubにConnect();で使われたデモソリューションのSmartHotel 360が公開されたので、forkしてみました。

ここから先はVSTS内のレポジトリをビルドするときと変わりありません。ビルド定義を作って、ビルドキューに入れてみます。

Hosted VS2017を指定します。

普通にビルド完了ですね。ちなみにこのソリューションのビルド結構時間がかかります。10分弱使いました。

コミット時にビルドする

GitHubの特定のブランチにコードがpushされたときにビルドする、pull request時にビルドするということもできます。

ただ、pull requestのビルドで外部レポジトリを指定した場合、git pullに失敗していました。これはちょっと調べてみます。それは置いといて、GitHubでpull requestしてみましょう。

devブランチを作って、適当に編集して、自分のmasterにpull requestをだしてみます。

mergeします。

今回はpull requestとmasterへのcommitでビルドのトリガーをかけているので、ビルドが二つキューに入れられています。pull requestでCIをかける場合、このようにビルドがキューにはいるので、注意してください。

masterへのコミットでビルドトリガーを指定しているので、自動的にビルドが実行されました。

ビルド結果の見方

ビルド結果ですが、自分がCIを設定しているので、mineハブを見ればいいか…と思うのですが、実はそうではありません。

GitHubのmasterにコミットされたコードのビルド結果は20171216.3ですが、mineハブで表示されているのは20171216.1という、最初に自分で明示的にキューに入れたビルドだけです。

実はpull requestなどのVSTSが外部イベントにより自動的に発生するビルドに関しては、mineには表示されません。以前はmineにこの辺のCIによるビルド品質レポートも含められていたのですが、わかりにくいということでフィードバックにより変更されました(私も最初わからなくて聞きました)。

TFS 2017ではたぶんこのレポートはCI含めて表示されているはずなので、見るときには気を付けてください。

CIおよび、ユーザーの明示的なビルド指示を含めて全部見たい場合はDefinitionsハブで見てください。

こちらはCIやほかの人が実行したビルド結果を含めて成功率が表示されます。

Visual Studio Team Services CI/CDアドベントカレンダー：異なるエージェントを使ってビルドする(15日目)

はじめに

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

qiita.com

6日目の記事で複数段階でビルドする、という機能を紹介しました。

kkamegawa.hatenablog.jp

その時はまだなかったのですが、Sprint 127の新機能でフェーズごとに別のエージェントが指定できるようになっています。今週中に展開が完了するということなので、もう使える方も多いと思います。ちょっとやってみましょう。

docs.microsoft.com

この機能はまだプレビューなので、Enable Preview Featureで有効にしてから試してください。

別のエージェントプールを追加する

Processのところで、Add agent phaseで追加します。これは前と同じですね。

前は選択できなかった、Agent queueが変更できるようになっています。せっかくなので、Hosted macOS Previewを選択します。

こちらは従来通り、Hosted VS2017を選択します。

こんな感じで複数のエージェントが構成できました。

ビルドもそれぞれできてますね。

並列実行は？

こんな風にparallel設定がありそうなので、複数のエージェントが並列でビルドできるのか…と思いきや、実はそうではありません。これはあくまでも「一つのエージェントフェーズ内で」の並列です。

docs.microsoft.com

具体的な用途としては、多くのUnit testを並列で動かすことができるのですが、そのためと思ってもらえればいいと思います。

並行ビルドの要望は出ているので、そのうち入るかもしれません。