kkamegawa's weblog

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

Visual Studio Team Services CI/CDアドベントカレンダー:Jenkinsと連携する(22日目)

はじめに

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

qiita.com

以前コードレポジトリの連携でGitHubを紹介しましたが、今度はビルドの連携でJenkinsを紹介します。

Serviceを設定する

VSTSからJenkinsを呼び出すにはふた通りのやり方があります。

  • Service Hookを使う
  • Service登録する

前者のService Hookは昔からある方ですね。今は後者のServiceを登録する方を押しています。Jenkinsのビルドタスクが用意されていますが、Serviceに登録されているエンドポイントを参照します。

f:id:kkamegawa:20171222221103p:plain

New Service EndpointからJenkinsを選択します。

f:id:kkamegawa:20171222221059p:plain

URL、ユーザー、パスワードを指定して、Verifyを実行して、Connectionが成功であればOKです。

f:id:kkamegawa:20171222221100p:plain

こんな風にService EndpointにJenkinsアイコンが出ていれば問題ありません。次はビルド定義を作りましょう。

ビルド定義作成

次はビルド定義を作ります。一つ注意点として、Jenkinsでソースの取得を行うので、デフォルトのソース取得を無効にしておきましょう。大きいプロジェクトだと無駄に時間がかから無くなります。

f:id:kkamegawa:20171222224527p:plain

このDon't sync sourceをチェックしておきましょう。

f:id:kkamegawa:20171222221101p:plain

Jenkinsのビルドタスクは二つ用意されています。

  • Jenkis Queue Job
  • Jenkins Download Artifacts

前者はJenkinsに定義したビルドキューを実行する、後者はJenkinsでビルドしたArtifactsをVSTSにダウンロードするというものです。どちらがビルドよう、リリース用ということはありません。Jenkins→VSTSと行ったビルドパイプラインでもいいでしょう。

f:id:kkamegawa:20171222221102p:plain

Queue Jenkins Jobを登録して、保存すると、Jenkinsのビルドジョブが呼び出せる…はずなのですが、投入はできるものの、404エラーになってしまいました…Blue Oceanで作ったビルドパイプラインを呼び出しているだけなのですが、よくなかったのかな。

リリース定義を作る

リリース定義を作ります。artifactの取得はリリース定義からと、ビルドタスクのいずれでも可能です。

f:id:kkamegawa:20171222230701p:plain

ArtifactのソースにJenkinsを指定して、サービスとジョブを指定すればArtifactsとして使用できます。

f:id:kkamegawa:20171222221107p:plain

もしくは、ビルドタスクで明示的にJenkinsのビルドタスクから取得するように構成します。こちらを使う場合、手動でリリースキューを実行することになるでしょう。

Service HookでJenkinsを構成する

Service Hookもまだサポートされています。Service Hook からServicesの一覧にあるJenkinsを選びます。

f:id:kkamegawa:20171222221105p:plain

Triggerからレポジトリ、ブランチ、コミットした人の設定を行えば、コードがコミットされるごとにJenkinsを呼び出すことができます。

f:id:kkamegawa:20171222221106p:plain

まとめ

Jenkinsに慣れている人(私以外w)は無理にVSTSのビルド機能を使わなくてもJenkinsを使い続けても大丈夫です。

.NET CoreにしてからがJenkinsでビルドしているようですしね。

Visual Studio Team Services CI/CDアドベントカレンダー:ダッシュボードでビルド/リリース状況を見る(21日目)

はじめに

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

qiita.com

今回はちょっと趣向を変えて、CI/CDの状態を見る方法について紹介します。個別の実行結果はSlackやTeamsに投稿すればいいのですが、全体の履歴としてみたい場合、ダッシュボードでぱっと見えると便利です。

VSTSのダッシュボードにはビルドやリリースの履歴、今何がどこに展開されているのかぱっとわかるウィジェットの貼り付けができます。全体表示させても便利です。

ダッシュボードの追加

Dashboardsの右端にある+をクリックすると、ダッシュボードの追加ができます。ダッシュボードの名前はわかりやすいものを付けてください。

f:id:kkamegawa:20171221185127p:plain

ウィジェット追加

ダッシュボードを作成してから、ウィジェットを追加します。拡張機能で追加するものを含めて、多くのウィジェットがありますが、CI/CDで関係あるもののみ紹介します。

marketplaceでウィジェットを探すとこれくらいあります。

marketplace.visualstudio.com

Chart for Build History

指定したビルド定義の所要時間、成功/失敗をチャートで表示するウィジェットです。重要なビルド定義を指定すればいいでしょう。

f:id:kkamegawa:20171221185128p:plain

チームプロジェクト内のビルド定義から履歴を表示したいビルド定義を選択します。一つのウィジェットに一つのビルド定義のみ設定できます。複数表示したい場合、ウィジェットを必要な数だけ登録してください。

f:id:kkamegawa:20171221185132p:plain

ビルド履歴はこんな感じで表示されます。バーが長いほどビルド時間がかかっています。途中伸びている項目がありますが、この時はなぜかHosted agentがものすごく遅かったためです。

f:id:kkamegawa:20171221185133p:plain

Deployment status

ビルド定義毎のビルド成果物がどの環境にリリースされているかという状況をクロス定義で見るためのウィジェットです。頻繁にデプロイするビルド定義が多いような環境では有用なウィジェットです。

f:id:kkamegawa:20171221185129p:plain

ビルド定義とViewを選択します。ViewはDeployment StatusTest Pass rateがあるので、お好みで。

ビルド定義と、ビルド定義の成果物が関連付けられているリリース定義を選択します。

f:id:kkamegawa:20171221185135p:plain

こんな感じで表示されます。何もやってないので、寂しいですが。

f:id:kkamegawa:20171221185136p:plain

Release Definition Overview

指定したリリース定義において、どのリリースがどの環境にデプロイされているか確認するためのウィジェットです。Chart of build historyのリリース版ですね。

f:id:kkamegawa:20171221185130p:plain

リリース定義を指定すると、現在の状況が表示されるので、問題なければこのままOKを押してください。

f:id:kkamegawa:20171221185137p:plain

Test Results Trend

ビルド定義、もしくはリリース定義で実行するテスト結果状況を表示するチャートです。テスト実行結果(成功/失敗)および、テスト実行時間もしくはその両方を合わせてチャートに表示できます。

f:id:kkamegawa:20171221185131p:plain

とりあえず簡単にテスト数を折れ線グラフにしてみました。全部成功(といっても2件ですが)しているので、100%のままです。

f:id:kkamegawa:20171221185138p:plain

完成

こうやってビルド、リリース関係のウィジェットを貼ったダッシュボードはこのようになります。ビルド関係が一目でわかるのでいいですね。

f:id:kkamegawa:20171221185139p:plain

もちろん、ビルド定義やリリース定義のカットでダッシュボードを作るとかでもいいでしょう。

ここでは紹介していませんが、Application Insightsを使っているのであればApplication Insightsのウィジェットを貼っておいて、常時モニターに表示しておくのもいいと思います。

残念ながらPower BIのVSTSコンテンツパックの提供が終わってしまいましたが、新しくODataでとってこれるようになったので、ODataを使って独自のチャートを作るのもいいかもしれません。

VSTS Analytics OData now publicly available – Microsoft DevOps Blog

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

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