Visual Studio Team Serviceのダッシュボードを使って作業を可視化する(20日目)

はじめに

VSTSのチームを開いたとき、ダッシュボードが表示されます。デフォルトでも必要十分な情報がありますが、やはりダッシュボードであるからにはwidgetを貼りたいものです。ということで、ダッシュボードのカスタマイズ方法を紹介します。

初期状態

初期状態ではこんな感じですね。Dashboardの編集権限があるアカウントでは右下に鉛筆マークが出るので、ここをクリックして編集します。

Welcomeタブをクリックすると、チームのWelcomeページが表示されます。これはwelcome.mdというファイルになっているので、それを編集すればいいです。

右上のスパナアイコンをクリックすると、ダッシュボードにタブを追加できます。今回はBuildというタブを追加して、ビルドやリリース関係の情報を集めます。

Auto-refreshにチェックすると自動的に更新されます。ビルド状態のようにいつ変わるかわからないデータを表示するタブではチェックしましょう。

Widget紹介

• Assigned to Me : ログオンユーザーに割り当てられている作業を表示します。初期状態で表示されています。
• Chart for Build History : 指定したビルド定義の成功・失敗および所要時間の概略をグラフにします。
• Chart for Work Items : 指定した作業項目の種類に応じてグラフにします。

• Code Tile : コードリポジトリに対して変更された数を表示します
• Deployment status : デプロイ状態を表示します
• Embedded Webpage : 外部のページをiframeで表示します。

• Markdown : Markdownで書いた簡単なメモを表示します
• New Work Item : 新規のWork Item(Backlog, Task, Featuresなど)を作ります
• Other Links : Feedbackクライアントなどを起動するためのリンクです。

• Pull Requests : Pull Requestの一覧を表示します。
• Query Results : Workタブで作成したクエリの実行結果を表示します。
• Query Tile : 指定したクエリの件数を表示します。

• Release Definition Overview : リリース定義ごとの状態を表示します。
• Requirements Quality : 要求項目に対する自動テストの品質を表示します
• Sprint Burndown : スプリントのバーンダウンチャートです

• Sprint Capacity : スプリントごとの作業許容量です。これはわかりにくいので、次のSprint Overviewを使うことをお勧めします。
• Sprint Overview : スプリントの残り時間と消化した作業の割合を表示します。
• Team Members : チームに所属しているメンバーを表示します

• Team Rooms : あまり出来が良くないチャットみたいなやつです。SlackやOffice 365のTeamsを使ったほうがいいでしょう。
• Test results trend : 指定したテストの品質をチャートにして表示します。
• Visual Studio Shortcuts : Visual Studioを起動するためのリンクがあります。まぁ必要ないでしょう。

• Welcome : Welcomeページの内容です
• Work Links : 作業項目のリンクです。

下にあるExtensions Gallaryをクリックすると、Widgetのギャラリーが表示されます。

今日現在で24種類登録されています。GitHubとかAzure Application Insightsのウィジェットは結構便利そうです。FREEのものが多いですね。

ビルド関係のWidgetを追加する

順番が変わりましたが、Buildタブにビルド関係のウィジェットを追加してみましょう。Markdownはビルド時の注意事項などを書いておけばいいでしょう。ウィジェット右上の…からスパナアイコンをクリックすると、ウィジェットの設定ができます。

Chart for Build historyではTitleとビルド定義を指定します。一つのウィジェットに一つの定義しか設定できません。ビルド定義が増えた場合、タブを分割するとか、全部みるとか、ダッシュボードで工夫してください。以下同じです。

Deployment Widgetでは、ビルド定義、ブランチ名、リリース環境名、テスト結果をどのグラフで見るか選択します。

Release Definition overviewでは、参照するリリース定義を一つだけ指定します。

Test results trendでは指定したビルドの単体テストの品質をグラフにします。

ビルド関係のウィジェットを貼り付けてみました。いちいち定義を見なくても一覧で見えるので非常に便利ですね。

Widget SDK

www.visualstudio.com

WidgetはJavaScriptとhtmlで作ってzipにして公開することになるようですね。VSTSの全機能はまだWeb APIでアクセスできない…はずなので、一部に限られますが、外部サイトの情報を表示するのでもいいと思います。

まとめ

ダッシュボードでの視覚化は凝り始めるといろいろできますが、ビルドステータスとかは結構すぐに使えていいと思いますよ。

Visual Studio Team Servicesの負荷テストをCI/CD時に実施する-JMeter編(19日目)

今日は追い込まれたので手抜きです(でも予定通りです)。

はじめに

VSTSの負荷テスト機能はVisual Studioだけではなく、Apache JMeterも対応しています。以前も少し紹介しましたが、多少強化されています。

kkamegawa.hatenablog.jp

制限事項

www.visualstudio.com

• JMeter 3.1をサポートしているという記述を見つけられません。一応試してみたのですが、Cookie Managerでエラーが出てしまいます。
• HTTPリクエストのみサポートです。
• 要素名に日本語を使わないほうがいいです。
• Graphなどのビジュアルを持つリスナーは使わないでください。

設定

Jmeter 2.13で設定します。

グラフィカルなリスナーを除外します。ちょっと色々試行錯誤しているのですが、最後の結果表示がうまくいっていません…。

(2016/12/20追記)
JMeterのThreadGroupの設定で、ループ回数を指定していると思いますが、「無限ループ」にチェックしてください。これを設定しないと、VSTSの負荷テストが指定回数で打ち切ってしまうので、正しくグラフが出るほど回数が実施されません。

Load TestからApache JMeter testをクリックします。

jmxファイルを指定します。

• Supporting files:動的に変更するパラメータファイルを指定します。
• Number of agents:同時に負荷をかけるエージェント数です。1エージェントで最大25userが同時にアクセスできるそうです
• Load duration:アクセスする時間です。
• Load location:実行するAzureデータセンターです。

ライセンスの計算は公開されていますが、1分であったとしても、最低250vuserが消費されるようです。

CI/CD時に実施する

ビルドタスクにJMeterがあるので、追加します。

• VS Team Service Endpoint:昨日紹介した方法でVSTSへのアクセスエンドポイントを指定します。
• Apache JMeter test files folder:jmxファイルが入っているリポジトリのフォルダ名を指定します。
• Apache JMeter file:jmxファイルをパスなしで指定します。
• Agent count:同時に使用するagent数です。
• Run Duration:実行時間です。なぜかここでは2分という設定ができます。

結果

結果ファイルはDownload ResultsでCSVとしてダウンロードできます。本当はVSTSでも見えるはずなのですが、なぜかうまくいっていません…もうちょっと調べます。

(2016/12/20追記)前述のとおりうまくいきました。

指定した分数の負荷がかかっています。JMeterのThread数がVSTSではUSER LOADに相当しています。

chartでもちゃんと出ています。

Azureの方でも負荷はかかっています(Application Insights設定忘れ…)。

ビルドもこんな風に成功しています。SSL関係でエラーが出ているようですが…。

まとめ

超手抜きですが、一応AzureデータセンターからJMeterでも負荷テストがかけられます。3.1に本当に対応しているのかとか、FTPもサポートして欲しいとか、色々要求はありますが、どうなっているのか、少し確認してみます。

(12/21追記)
やはりまだJMeter 3.xには対応していないようです。UserVoiceでも要求が出ているので、voteしてみてください。2.13で作ったjmxを編集してもうまく動くことは動くようですが、保証はできません。

How can we improve Team Services?

• 11 votes
• 1 comment

Support jMeter 3.0

Please upgrade support for jMeter load tests to support the latest version.

Right now, the supported version for jMeter test scripts in Visual Studio Online is v2.13 (c.f. https://www.visualstudio.com/en-us/docs/test/performance-testing/getting-started/get-started-jmeter-test#jmeter-tests).

...

visualstudio.uservoice.com

Visual Studio Team Servicesの負荷テストをCI/CD時に実施する(18日目)

はじめに

昨日は単体で実施する負荷テストを紹介しました。たまにやる分にはGUIでちまちま実施しても構いませんが、どうせなら継続的インテグレーション(CI)や継続的デプロイ(CD)に組み込みたいものです。

VSTSのビルドタスクにはVSTSのLoad Testを呼び出す機能があります。今日はそれを紹介します。

負荷テストプロジェクトを登録する

負荷テストのひな型を入手する

VSTSのCI/CDで負荷テストを実施するにはまずロードテストソリューションを登録します。最初から作ってもいいのですが、せっかくなので、GUIで作ったテストをそのまま使いましょう。

Load Testの結果から"Export test to Visual Studio"をクリックすると、負荷テストのソリューションがzipファイルで入手できます。いつも通り右クリックから「ブロックを解除」(もしくはPowerShellでunblock-fileコマンドレット)してから開きます。

ソリューションを開くとこんな感じで負荷テストの設定が一式入っています。

LoadTestProjectを開くとこんな感じでシナリオやWebテスト、負荷をかけるデータセンターの設定が入っています。特に事情がない限り、変更する必要はありません。

Visual Studioで負荷テスト結果を参照する

ちょっと話がずれますが、負荷テストソリューションを開くと、Visual Studio内にロードテストという項目ができます。

ロードテストメニューの「ロードテストマネージャー」を開くと、VSTSで実施したロードテストの結果が見えます。

調べたい結果をクリックするとVisual Studio内で結果が確認できます。Performance,Throughput, Applicationのログが確認できます。

Throughputもこのように確認できます。Applicationを調べるにはMonitoring Agentが必要なので、App Serviceそのままでは確認できません。

ソリューションを追加する

開いた負荷テストソリューションはもちろんソース管理の対象にできます。ここではチームプロジェクトのGitリポジトリに登録します。

こんな風にWebサイトのプロジェクトと同じリポジトリで管理してみました。負荷テストを設定する都合上、同じチームプロジェクトであれば、異なるリポジトリでもOKです。

VSTS負荷テストをCI/CDで呼び出せるように設定する

VSTSのビルドパイプラインで負荷テストを呼び出せるようにするには、サービスのエンドポイントに登録しなくてはなりません。まずはPersonal Access Tokenを設定します。All scopeで構いません。APIKEYはなくさないようにしましょう。

ServicesからNew Service Endpointをクリックします。Genericをクリックして、以下の指定をします。

• わかりやすい名前
• Server URL:自分のVSTSのホスト名
• User Nameには管理者のアカウント名
• Token Keyには先ほど作ったAPI KEY。

ビルド定義に追加する

簡単なURLテスト

ビルドもしくはReleaseのタスクにCloud-based Web Performance Testを追加するとCI/CDでURLへのアクセステストができます。例えば、デプロイして特定のURLに一定数のユーザーがアクセスしても例外が起きているかどうか、という用途に使えます。

• VS Team Services Connection : Servicesで追加したエンドポインt
• Website Url : アクセスするURL
• Test Name : テスト名
• User Load : ユーザー数
• Run Duration : 実行時間
• Load Location : アクセス元データセンター
• Run load test using : 負荷テストをかけるのを自動管理か自前管理か

ビルドをキューに入れるとこんな感じで結果が出ます。アクセス例外が出なかったので、ビルドが成功したことになっています。

VSTSの負荷テストをビルド時に実施する

次はVSTSの負荷テストと同等のテストを実施します。毎回ビルド時に実施すると時間がかかりすぎるので、工夫が必要になります。

例えば、特定のスケジュールでリリースする前に実施するとか、不定期にブランチを作って、そのブランチを検証用の環境にデプロイしてやってみるとか、といった感じでしょうか。

ビルドタスクを作ってみました。負荷テストソリューションをビルドして、publishしてから、Cloud Load Test タスクを実行します。

• Test settings file:ソリューション内にある拡張子testsettingファイルです。VSTSが作ったものであればCloud.testsettingというファイルです。
• Load test files folder:負荷テストソリューションがあるフォルダ名です。
• Load test file : 負荷テストシナリオを登録しているWeb Performance Testプロジェクトです。VSTSが作ったものであれば「テスト名+WebTest.loadtest」となっています。
• Number of permissible threshold violations : 何回以内の例外であればOKとみなすかという判定です。

ビルドログでは例外が3回だったので、問題ないと判定されます。

ということでビルドも成功しました！

まとめとRelease Managementでの補足

VSTSの負荷テストをCI/CDで実施できるのは定期的に負荷テストをかけたいというシナリオにおいてとても便利です。特に大きな改造をした場合は、ビルドやリリースタスクに追加しておくといいでしょう。

今回リリースでの組み込みは(時間の関係でｗ)実施しませんでしたが、コツとしては変わりありません。

必ずビルド時のartifactsに負荷テストソリューションを追加しておかないと、Release Managementで負荷テスト実施のシナリオが参照できないという点に注意してください。

Visual Studio Team Servicesを使ってWebサイトの負荷を簡単に計測する(17日目)

はじめに

Webサイトをリリースして、著名なメディアに取り上げられるなどの何らかの事情で、突発的にアクセスが増えてダウンした、ということはよくあります。そういうことがなくても、導入の要件で最低アクセス人数を指定されているということもよくあります。

Visual Studioの負荷テスト機能をはじめ、Load Runnerなどの商用製品やjmeterのオープンソースのツールを使うこともあるでしょう。VSTSはクラウドサービスらしく、Azureのデータセンターから負荷をかけるという機能があります。

何度か@ITなどで紹介したこともありますが、さらに進化を遂げています。今日は簡単なURLを指定して負荷をかける機能を紹介します。

URLベースのシナリオを作成する

Load Testをクリックすると、初期画面が表示されます。今日紹介するのはURLとhttp archiveです。

右から二番目にあるURLの下にあるCreate testをクリックすると、シナリオ作成画面になります。

アクセスをかけるURLおよび、httpヘッダ、クエリパラメータを指定します。

こんな風にトップページ、About, ContactのURLを順番にアクセスするというシナリオを作りました。

Settingsで負荷の設定を行います。

• Run duration:負荷をかける時間です
• Load pattern:均等にかける(Constant)、徐々に上げる(step)
• Max vusers:シナリオにおける最大ユーザーです。20000ユーザー/月まで無償で実行できます。ただし、負荷の時間によって、25×実行時間でユーザー数を消費します。ちなみにこのパターンでは250ユーザーを消費します。
• warmup duration:負荷をかけるまでの待機秒数です
• Browser Mix:ChromeとIEのアクセス比率を指定します。
• Load location:どのデータセンターから負荷をかけるかという指定です。東京と大阪も指定できます。

負荷をかけるとこのような結果が表示されます。chartをクリックすると、グラフで表示されます。

性能、スループット、エラー数が表示されます。

Diagnosticsでは発生した例外、情報が表示されます。これはAzure App ServiceのBasic B1で動いているので、CPUが1つです。Basic B2の2CPUに変更して同じ負荷をかけてみます。

数値とグラフも変わっています。

しかし、このような数値だけではわかりづらいですね。そういうときのために設定前後の実行結果を選択して、"Compare two runs"をクリックすると、チューニング前後で比較できます。

baseline(最初に取得したデータ)と現在のデータで比較して、どのくらい負荷が減ったか一目でわかります。

…減ったと言いたいところですが、App Serviceのスケールを変えた後の再起動後の初回起動で性能が悪化してますね(^^;。負荷テストのときはこういうことがあるので、気を付けてください。

ブラウザのリクエストをそのまま使用する

har(HTTP archive)を取得する

負荷テストのリクエストの作成はいつも結構苦労します。fidderでキャプチャして、リクエストを見ながらということが多いのではないでしょうか。

VSTSの負荷テストではブラウザが発行したリクエストを保存して転用する機能があります。

Chromeのf12ツールのネットワークタブでリクエストを右クリックして、「生を付けて保存」すると、該当リクエストをharファイルとして保存できます。

Edgeでも同様にf12開発者ツールで保存できます。

HTTP Archive based testを作成

Newから"HTTP Arvhice based test"をクリックします。

ダイアログが表示されるので、保存したharファイルを指定します。

リクエストが追加されます。追加されるリクエストは外部のCDNなども入っているので、不要なリクエストは消してください。

こんな風に同じリクエストが作れました。http headerとかQueryStringも入るので、便利です。ただし、リクエストごとに保存して追加という手順を踏まないといけないんですかね？この辺は拡張機能か何かあってもよさそうに思いますが…。

自動的にリダイレクトするようなサイトだと難しいかもしれませんが、自分でヘッダやQueryString設定しなくてもいいのは便利だと思いますので、使ってみてください。