リリース管理でテストを自動化する方法-パート1

2015年11月、Visual Studio Team Servicesでの公開テスト用にリリース管理バージョンのサービスを開きました。 このブログの資料は、すべてのRM機能をすぐに使い始めるのに役立ちます。 ここで利用できるMSDNドキュメントを使用すると、RMスクリプトと概念をより深く理解できます。



RMサービスは、使用する複数の環境でコードを実装する場合と、製品開発中にテストを実行する場合の2つのシナリオで使用できます。 この投稿では、2番目のシナリオ、つまり、私たち（MicrosoftのRMチーム）がRMを使用してテストを自動化する方法について説明します。 7か月間、テストにRMを使用してきました。同僚のLovaに感謝します。



この記事を2つの部分に分けました。 最初の部分は、統合テスト自動化の経験の一般的な説明です。 2番目の部分では、いくつかの設計ソリューション、テストの自動化プロセスで発生した問題、およびこれらの問題を解決する方法に焦点を当てます。

概要と一般的な説明

VSTSは複数のスケールユニット（SU）で構成され、バージョン管理、アセンブリ、リリース管理、作業項目の追跡などのサービスを提供します。VSTSツールの開発と使用に関与するすべてのグループは、日常業務でSU0を使用します。 したがって、SU0は「作業オプション」です。 原則として、グループは最初に新しいコードをSU0にデプロイし、しばらく試してから他のスケーリングユニットに転送します。



同様に、RMは日常業務でSU0のサービスを使用します。 features / rmmasterというTF Git機能ブランチで開発（コードの更新と修正）を行い、Buildサービスを使用してコードをコンパイルし、RMサービスを使用してテストします。



テクニカルシステムの一般的な目的は、さまざまな構成で各テストを同時にテストして、開発サイクルのリグレッションをできるだけ早く検出することです。 現在、開発されたコードのデバッグには3つの段階があります。

1. 予備チェック段階または行われた変更を含めるための要求 ：この段階では、機能/ rmmasterブランチの基本機能の正しい動作を保証するために、主にユニットおよびいくつかの複雑なテストを実行します。
   • gitブランチで検証が許可されている場合、このステップは実行されないことに注意してください。
2. 継続的インテグレーション（CI）ステージ：このステージでは、検証後すぐにCIアセンブリが動作を開始します。 このアセンブリでは、ユニットテストをもう一度実行し、並列チェックでエラーが発生しないことを確認してから、テストを自動化するためにRMチームが使用したアーティファクトを公開します。
3. テスト自動化フェーズ ：アセンブリの最後から開始され、並行して起動される一連のリリース定義（RD）が含まれます。 各リリース定義は特定のシナリオをテストします。 出力の定義は、製品全体をまとめてカバーします。 この出版物のこの段階では、最も注意を払います。

「継続的な自動化パイプライン」のセットアップ

継続的統合CIアセンブリの名前はVSO.RM.CIです。 アセンブリは、実行の結果として作成されたすべてのバイナリファイルを含む「ドロップ」と呼ばれる単一のアーティファクトを公開します。





リリース定義トリガープロパティを使用して、このアセンブリ定義をリリース定義のセットに関連付けます。 つまり、以下で強調表示されている各リリース定義は、VSO.RM.CIビルドの終了時に自動的にアクティブ化されます。





（各リリース定義には固有の環境があることに注意してください。RMはメディアの並列実行をサポートしないため、9つのリリース定義を使用せざるを得ません。この機能はまもなく登場します。この場合、9つのリリース定義を1つのリリース定義に結合しますアセンブリのトレーサビリティを向上させる9つの同時環境があります）。

一般的な考え方は、各リリース定義がテストに必要なバイナリをダウンロードし、テスト環境をセットアップし、古いバイナリと新しいバイナリ（依存サービスとテストDLL）を削除し、VsTestタスク（結果を発行する）を使用してテストを実行することです、レポートの準備とその後の分析を簡素化します）、もう一度環境をクリーンアップします。 後で、このブログのリリース決定デバイスを詳しく見ていきます。

コードを処理してテストを公開するプロセスは、概略次のとおりです。

エージェントプールの構成

開始するには、最初に継続的統合CIアセンブリおよびリリース定義のビルド/リリースエージェントを構成する必要があります。 通常、一部のサーバーでは、RM / SPS / TFSサービスを展開するために、ビルド/リリースエージェントプールのタスクが最初に起動され、これらのタスクのために他のサーバーでテストが実行されます。 この場合、同じテストの複数のインスタンスを同時に使用するために、エージェントコンピューターにサービスを展開することにしました。



各テストには独自の要件があり、ホストされたエージェントプールの使用は許可されませんでした。 このため、RMAgentPoolという単一のエージェントプールを作成しました。 RM.CDPごとに個別のコンピューターを用意しました*リリース定義、それぞれにビルド/リリースエージェントをインストールし、これらのコンピューターをRMAgentPoolプールに追加しました。



（これを行うために、下の図で強調表示されている[エージェントのダウンロード]リンクを使用して、各テストコンピューターにエージェントをダウンロードしました）。 エージェントのzipファイルを解凍し、「Team Foundation ServerのURL」パラメーター（「Team Foundation ServerのURL」）でアカウントを指定して構成しました（例： https : //OurAccount.visualstudio.com ）。



各コンピューターには、「RmCdpCapability」と呼ばれる新しいユーザー機能が割り当てられています。 このパラメーターの値によってコンピューターの目的が決まりました。たとえば、連続統合アセンブリ用に準備されたコンピューターでは、パラメーターRmCdpCapability = CIが使用されました。





別の例：RM.CDP.TfsOnPremリリース決定が実行されたエージェントでは、パラメーター「RmCdpCapability = TfsOnPrem」が使用されました。







次に、リリース定義は、RmCdpCapabilityパラメーターを、適切なエージェントで実行するテストの要件として使用しました。

RM.CDPリリース定義の概要*

用語に関する注記：Webクライアントに基づくRMは、Team Web Access（TWA）とも呼ばれます

• VSTSのRM TWAサービスはRM Online（またはRMO）と呼ばれます
• ローカルTFSバージョン管理システムのRM TWAサービスはRMオンプレミスと呼ばれます（このサービスはまだリリースされていませんが、できるだけ早くリリースできるようにあらゆることを行っています）

VSTSは、単一のSprintモデルを使用して開発される複数のマイクロサービスのセットであることに注意してください（すべてのグループは同じ3週間サイクルで動作します）が、各グループは互いに独立して展開されます。 RMはそのようなマイクロサービスの1つであり、SPSやTFSなどの他のマイクロサービスに依存しています。

RM TWAに対して実行するテストの簡単な説明：

1. RMOのテスト：
   • RM.CDP.RmEqTfs：RMスプリントリリースと依存サービス（SPS、TFS）のバージョンが一致する場合、RMOのAPIに基づいて複雑なテスト（e2e）を実行します。 たとえば、RM、SPS、およびFTSはS92スプリントにあります。
   • RM.CDP.RmGtTfs：RMリリースバージョンがスケールユニットの依存サービス（SPS、TFS）よりも先にある場合、RMOリリースバージョンの複雑なテスト（e2e）を実行します。 たとえば、RMはS92にあり、SPS / TFSはS91にあります。
   • RM.CDP.RmLtTfs：RMリリースバージョンがスケールユニットの依存サービス（SPS、TFS）の背後にある場合、RMOリリースバージョンの複雑なテスト（e2e）を実行します。 たとえば、RMはS91にあり、SPS / TFSはS92にあります。
   
   
   上記のテストマトリックスにより、依存するSPS / TFSサービスが展開されているかどうかに関係なく、スケール単位でRMOを展開できます（これらのサービスが新しい機能に依存していない場合;この場合、RmGtTfsテストスイートは失敗します、少なくともそうすることを望みます） 。
2. RMオンプレミステスト：
   • RM.CDP.TfsOnPrem：APIとユーザーインターフェイスの両方に基づいてRMオンプレミステストを実行します。
3. テストを更新する
   • RM.CDP.DevFabricUpgrade：RMOアップグレードスクリプトをテストします（たとえば、S91からS92へ）。
   • RM.CDP.OnPremUpgrade：RMオンプレミス更新スクリプトをテストします。
4. X-plat RMテスト、すなわち RMエージェントはLinux / iOSで実行されます。
   • RM.CDP.XPlat

RM.CDPリリース定義の開発*

RM.CDP.TfsOnPremリリース定義は、他のリリース定義で使用される標準的なテンプレートを作成するので、詳しく見ていきます。

1. 以下のスクリーンショットに示すように、リリース定義は適切なエージェントで実行されるように構成されています 。RM.CDP.TfsOnPrem->編集->環境-> ...->エージェントオプション->オプションタブ。
2. 次に、リリース定義はアーティファクトのダウンロードをスキップします（アーティファクトのダウンロードをスキップ） ：
   
   
   
   
   
   CIの継続的インテグレーションアセンブリは、数GBのサイズのドロップと呼ばれる唯一の大きなアーティファクトを公開するため、アーティファクトのダウンロードはスキップされますが、すべてのテストには異なるファイルのサブセットが必要です。
   
   （現時点では、RMでは、アセンブリによって公開されたアーティファクトのサブセットを簡単にダウンロードできません。この機会が現れたら、次の2つのことを行います。（1） 「RmDrop」、「SpsDrop」など（2）RM.CDPのリリースを決定するために必要なアーティファクトをダウンロードします*）。
3. 各リリース定義は、\\ファイルリソースにあるdownloadArtifacts.ps1ファイルを実行して、標準ファイルのセット（アセンブリの特定のフラグメントをダウンロードできるvssbinfetch.exeプログラムを含む）をダウンロードします。 次に、リリース定義は、vssbinfetch.exeプログラムを呼び出す「vssbinfetch」タスクを使用して、テストスクリプトのアセンブリから必要なバイナリをダウンロードします 。 たとえば、RM.CDP.RmEqTfsはSPS、TFS、およびRMOのバイナリファイルをダウンロードし、RM.CDP.TfsOnPremはTFSをオンプレミスでダウンロードします。 これらの2つのタスクを以下に強調表示します。 リリースを決定すると、同時にコンピューターがクリーンアップされ、古いバイナリが削除されます。
   
   
4. 次に、リリース定義により、必要なサービスとdllテストライブラリがコンピューターに展開されます。 たとえば、tfatはコンピューターにTFSオンプレミスサービスをインストールする内部ツールです。
   
   
5. 最後に、リリース定義はテスト環境ファイルをセットアップし、Visual Studio Testタスク（または使用したいVsTestタスク）を呼び出します。 これにより、「TfsOnPrem」という名前でテスト結果が公開されます。
   
   
6. 通常、リリースの決定は、「テスト失敗時にエージェントを一時停止」タスクが完了し、必要に応じてクリアされた後に完了します。 原則として、「一時停止」タスクは無効になっています。これについては、次のブログ投稿で説明します。

テスト結果分析

開発者が変更を加えると、誰の変更が失敗の原因となったかを簡単に判断できます。 たとえば、次のスクリーンショットでは、VSO.RM.CI_rmmaster_20151231.5のビルド後にテストが失敗しました。 強調表示されたリリースをダブルクリックして、リリース概要ページを開きます。





次に、[リリースの概要]ページの[テスト結果]セクションに移動し、このテストの後、2つのユーザーインターフェイステストが失敗し始めたことを確認します。 以下で強調表示されているテストへのリンクをクリックすると、テストセクションに移動します。





[テスト結果]サブタブは、問題の詳細な分析のための貴重な背景情報を提供します。





テストログは、[実行の概要]サブタブで利用できます。

リリースサマリページの[コミット]タブを使用して、リグレッションとの可能な関係を判断するために、このリリースの固定に関する詳細情報を取得できます。 たとえば、次のスクリーンショットは、このテストでのユーザーインターフェイスの変更によって、2つのテストが失敗する可能性があることを示しています。

RMを使用したテストの利点

RMを使用したテストには、次の利点があります。

1. すべてのテストスイートを並行して実行して、アセンブリをすばやく検証します。
   • 最も遅いリリース定義を検出し、テストスイートを実行するために追加のエージェントを追加して、並列処理を高速化できます。 たとえば、継続的インテグレーションを構築するために2台のコンピューターがあり（「RmCdpCapability = CI」）、RM.CDP.RmEqTfsには別のコンピューターを追加する予定です。完了に時間がかかるためです。
2. この設定により、さまざまなブランチを簡単にテストできます。 機能ブランチ（features / rmmaster）に継続的な統合が構成されているため、下のスクリーンショットに示すように、releases / M92などのリリースブランチからアセンブリをキューに入れることができます。 ビルドの最後に、同じRM.CDP。*リリース定義がアクティブ化され、このリリースブランチからのバイナリコードが処理されます。
   • ブランチでの柔軟な作業は、次のシナリオで拡張できます：開発者にとって面倒になる前にコードをテストします（ルールとして、開発者が多数の変更を行う場合に実行する）。たとえば、/ users / rahudha / rifiブランチで。 主なアイデアは、開発者がグループのリソースを再利用することで、開発環境にテストインフラストラクチャをセットアップせずに同じ問題を解決できるということです。
   
   
   
3. 自動テスト環境と同じテストを実稼働環境で実行できます：RMOを使用して実稼働環境に展開するため（これがRMOを使用してRMOを展開する方法です）、同じテストタスクを使用して展開をテストできます。
4. すべてのテストスイートが同じバイナリコードセットに適用されるため、「ビルド品質とは」という質問に簡単に答えることができます。原則として、ビルド環境を実稼働環境に展開する前にビルド品質について知りたいと思います。 以下のスクリーンショットは、ビルド品質を決定するための簡単なクエリを示しています。
   
   

（今後数か月以内に、この機能はリリース概要ページとさらに統合される予定です。

おわりに

最初は、開発プロセスをテストするときにRMOを使用して、その機能を理解するだけでした。 時間が経つにつれて、RMOの有効性は以前に使用したテストインフラストラクチャの有効性よりも大幅に高いという結論に達しました。 開発者は、時間のかかるローカルテスト環境のセットアップなしに、主要な変更をテストできることを好みます。



これで、RM開発チームがRMを使用してテストを自動化する方法がわかりました。 私たちの経験が、テストプロセスを自動化する方法についてのアイデアを提供することを願っています。



この記事の第2部では 、いくつかの設計ソリューション、リリース管理の編成プロセスで発生した問題、およびこれらの問題を解決する方法に焦点を当てます。