kkamegawa's weblog

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

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

はじめに

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

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

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

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

f:id:kkamegawa:20161218203954p:plain

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

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

f:id:kkamegawa:20161218203956p:plain

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

f:id:kkamegawa:20161218203957p:plain

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

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

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

f:id:kkamegawa:20161218203958p:plain

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

f:id:kkamegawa:20161218203959p:plain

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

f:id:kkamegawa:20161218204000p:plain

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

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

f:id:kkamegawa:20161218204001p:plain

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

f:id:kkamegawa:20161218204002p:plain

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

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

f:id:kkamegawa:20161218204003p:plain

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

f:id:kkamegawa:20161218204004p:plain

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

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

ビルド定義に追加する

簡単なURLテスト

f:id:kkamegawa:20161218204006p:plain

ビルドもしくは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 : 負荷テストをかけるのを自動管理か自前管理か

f:id:kkamegawa:20161218204007p:plain

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

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

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

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

f:id:kkamegawa:20161218204632p:plain

ビルドタスクを作ってみました。負荷テストソリューションをビルドして、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とみなすかという判定です。

f:id:kkamegawa:20161218204630p:plain

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

f:id:kkamegawa:20161218204631p:plain

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

まとめとRelease Managementでの補足

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

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

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