kkamegawa's weblog

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

Visual Studio Team Services CI/CDアドベントカレンダー:継続的モニタリングを設定する(20日目)

はじめに

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

qiita.com

継続的インテグレーション、継続的デプロイ(デリバリー)はよく聞いたことがあると思います。最近VSTSの開発で継続的モニタリングという言葉もでてきました。VSTSのリリーステンプレートにも入っています。

どんなものかちょっと見てみましょう(CI/CDじゃなかったのかという突っ込みは…)。

リリース定義の作り方

リリース定義にAzure App Service Deployment with Continuous Monitoringがありますので、選んでみます。

f:id:kkamegawa:20171221000909p:plain

二つEnvironmentがありますが、すでに一度作ったものに追加する形でキャプチャ撮ったので、スルーしてください。

f:id:kkamegawa:20171221000910p:plain

モニタリングのテンプレートから作った場合、以下の三つのタスクが定義されています。

  • Enable Continuous Monitoring
  • Configure Application Insights..
  • Azure App Service Deploy

これを見てわかると思いますが、「App ServiceにデプロイするついでにApplication Insightsを定義してやるよ」ということをリリース定義でやってくれるものです。Enable Continuous Monitoringは要はApplication Insights拡張機能を指定したWeb Appsに設定してくれるというものです。

f:id:kkamegawa:20171221000911p:plain

次のConfigure Application Insightsタスクで、Application Insightsの監視ルールが設定できます。実はこのタスクで作った場合、既定の設定が選択されているので、その設定をそのまま使っても構いません。

f:id:kkamegawa:20171221000912p:plain

  • Availability が99%を下回った場合
  • リクエスト失敗が5回より大きい
  • サーバーの応答時間が5秒より大きい場合
  • サーバーの例外が5回を上回った場合

ここでサブスクリプションの所有者、コントリビューター、読み取り権限のある人、その他指定した人にこのアラート条件を満たしたときにメールを送信する設定もできます(Subscription owners.. にチェック)。

これ以外の警告条件を指定したい場合もあります。Alert rulesの横をクリックして、条件設定をします。

f:id:kkamegawa:20171221000913p:plain

警告名、メトリクス、条件、閾値を指定します。余り警告が来てもあれなので、許容できる範囲を合意しておきましょう。

f:id:kkamegawa:20171221000914p:plain

メトリクスにはWebサーバーで大体要求されるような項目が入っていると思います。

f:id:kkamegawa:20171221000915p:plain

App Serviceのデプロイには特に問題はありませんね。

f:id:kkamegawa:20171221003044p:plain

実際これをリリースしてみると、Application Insightsの警告ルールに設定されています。

まとめ

Application Insightsにはメトリクスをとる機能と、ログを出力する機能があります。今まではどちらもVisual Studioのウィザードで設定することが多かったと思いますが、モニタリングに関してはCDのタスクで設定できるようになりました。

メトリクスルールもCDで構成できるので、これを仮に複数のリージョンに展開するとなったときでも既存のリリース定義から複製すればいいだけなので、Azureポータルでぽちぽち手作業するのにくらべて、間違いが起きなくなります。

また、リリースに含まれるので、アラートルールを変更する場合でもリリース定義を変えることにより、記録として残るので、とても便利だと思います。

使ってみてください。

Visual Studio Team Services CI/CDアドベントカレンダー:ビルド時のユニットテストと品質履歴を参照する(19日目)

はじめに

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

qiita.com

今まであまり触れてきませんでしたが、VSTSで単体テストを実施するとテストの成功率やカバレッジの記録が採取できます。これを履歴で見るとカバー率の履歴が分かります。どんな感じで表示されるのか、紹介します。

.NETでやっていますが、JavaであってもJaCoCoのコードカバレッジ形式に対応しているので、ほぼ同じことができるはずです。

テストタスクを構成する

Visual Studio Testというタスクがあるので追加します。設定できるところは非常に多いのですが、重要なポイントだけ解説します。

f:id:kkamegawa:20171219210210p:plain

vstestが認識するテスト結果のフォーマットを指定します。JUnit, NUnit, VSTest, XUnitが選択できます。

f:id:kkamegawa:20171219210208p:plain

テストアダプターのバージョンが特定のものでないといけない場合に指定します。通常はlatestで構いません。

setting fileはテストの実行時フィルタリングや明示的に設定を与えたい場合に指定します。通常、.runsettingsというファイルです。フォーマットはこちらを見てください。

.runsettings ファイルを使用して単体テストを構成する | Microsoft Docs

f:id:kkamegawa:20171219210209p:plain

テストを並列や複数のマシンで実行する設定です。ここはマルチフェーズビルドを実施する際に指定します。通常はチェックなしで構いません。

Run test in isolationはテスト実行時の分離モードを指定します。テストによっては指定しないと警告が出ますが、遅くなることがあります。

Code coverage enabledはコードカバレッジを取得します。ユニットテストであれば指定することをお勧めします。ただし、.NET Coreではまだコードカバレッジを採取する仕組みがないはずなので、実行しても無視されます(山のようにリクエストは出ています)。

f:id:kkamegawa:20171219210217p:plain

Select test usingにはTest assemblies, Test plan, Test runが選択できます。ユニットテストではTest assembliesを選択すれば自動的に対象の名前(Testsに一致するプロジェクトが生成するアセンブリ)をユニットテストと認識して実行します。

Test planはいわゆる自動テストです。Testハブからテスト計画を作ってテスト対象プログラムを自動実行します。

Test Runはテスト実行らしいのですが…どうも、テストの実行IDを指定して履歴を見るような感じなんでしょうか。まだ使ったことがないのですが、こちらを見てください。

Run automated tests from test plans in the Test hub VSTS and TFS | Microsoft Docs

テストは実行するだけでは品質データとして蓄積されません。Publish Test Resultsタスクを使ってVSTSに発行します。

f:id:kkamegawa:20171219210211p:plain

テスト計画を作る

Test Planを選択した時、TestハブでPlanを作ります。Planの名前とArea Path, Iterationを指定します。

f:id:kkamegawa:20171219210212p:plain

Planを作った後はテストケースを構築します。テストのシナリオを作り、具体的なステップを書いていきます。CI/CDアドベントカレンダーからははずれるので、深入りしませんが、ドキュメントを参考にどうぞ。

docs.microsoft.com

ビルドと品質レポート

ビルド時にカバレッジとテスト結果を発行していると、TestタブにUnitTestの結果が表示されます。このときはテストケースが一つだったので、Test数が1で100%成功ですね。

f:id:kkamegawa:20171219210213p:plain

Summaryにはコードカバレッジの結果も出ています。ブロックで50%、ソースコード行数で58%カバーしています。

f:id:kkamegawa:20171219210216p:plain

テストケースを一つ増やして2にすると、ブロックが57.89%, ソースコード行数が64.71%に向上しました。赤枠で囲んでいるところでカバレッジが上がったことが分かります。

f:id:kkamegawa:20171219210215p:plain

Download codecoverageをクリックすると、Visual Studioで開けるコードカバレッジ結果ファイルがダウンロードされます。

f:id:kkamegawa:20171219210218p:plain

未カバー率が100%のところがあるので、ダブルクリックすると、Visual Studioで該当ソースコードが開きます。

f:id:kkamegawa:20171219210219p:plain

赤で塗られているところが未カバー範囲で、薄い水色がテストでカバーされているところになります。

Visual Studio Team Services 2017/12/11の更新

六週間後かと思っていたのですが、二週間で出てしまいました。今回のリリースは少しだけで、一週間で展開されるということなので、もう皆さん使えるようになっていると思います。オリジナルのリリースノートはこちらを読んでください。

docs.microsoft.com

今回重要な注意事項として、SSHでログインしている場合、URLが変わるので、早く対応しましょう。ケースによっては5倍くらい早くなるというのは魅力的ですね。

複数フェーズビルドが強化されてそれぞれ別のエージェントキューが指定できるようになったのはいいですね。.NET Coreのように複数のプラットフォームでビルドしたい場合とか便利そうです。

Hosted VS2017エージェントに管理者権限でソフトが追加できるようになるのは地味にうれしいです。管理者権限で追加できるのは大丈夫なのかという気もするんですが…うーん。

ではまた三週間後。

Translate to Japanese to VSTS release notes from h ...

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をクリックします。

f:id:kkamegawa:20171218205721p:plain

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

f:id:kkamegawa:20171218205720p:plain

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

f:id:kkamegawa:20171218205724p:plain

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

f:id:kkamegawa:20171218205726p:plain

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

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

f:id:kkamegawa:20171218205727p:plain

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

f:id:kkamegawa:20171218205728p:plain

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

f:id:kkamegawa:20171218205725p:plain

nugetパッケージのCI

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

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

f:id:kkamegawa:20171218205717p:plain

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

f:id:kkamegawa:20171218205718p:plain

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

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

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

f:id:kkamegawa:20171218205716p:plain

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

f:id:kkamegawa:20171218205715p:plain

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

f:id:kkamegawa:20171218205719p:plain

クロスプラットフォーム対応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 のビルドエージェントがいつもより遅かった気がする)、ビルドの無償枠がだいぶ溶けました…。