Visual Studio Online：継続的な統合とテスト

Team Foundation Server 2015のようなVisual Studio Onlineには、継続的な統合プロセスを実装する機能があります。

この記事では、GitリポジトリでVisual Studio Online（VSO）を使用する例と、継続的な統合、テスト、および自動展開プロセスを構成する方法について説明します。

Visual Studio Onlineサービスをセットアップすることは、さまざまなプラットフォーム用のアプリケーションを構築および展開するプロセスを整理および計画するための最速の方法の1つです。 サービスは、別個のサーバーにインストールまたは構成する必要なく、クラウドインフラストラクチャに数分以内に展開および起動します。

VSOとGitを使用する

VSOでプロジェクトを作成し、リモートGitリポジトリを初期化する

チームがVSOで作業するための新しいプロジェクトを作成しましょう。 VSO Webサイトにアクセスし、メインページに移動して、[新規]をクリックします。



プロジェクトの名前と説明を示します。 開発プロセスを実施するために必要なテンプレートを選択します。
ここでは、バージョン管理システムとしてGitを選択し、[プロジェクトの作成]ボタンをクリックします。



プロジェクトが作成されたら、[プロジェクトに移動]ボタンをクリックします。



私たちのチームの仕事のためのプロジェクトのメインページが表示されます。 ここで、Gitリポジトリを初期化する必要があります。 CODEページに移動し、「ReadMeファイルを作成」​​をクリックします。 リポジトリが初期化され、masterブランチが作成されます。 例として、このブランチで継続的統合を構成します。



スクリーンショットでは、README.mdファイルを含むmasterブランチが表示されています。

Visual Studioでプロジェクトを開き、Gitリポジトリを複製してソリューションを作成します。

チーム用のプロジェクトを開き、Visual Studioで作業し、リポジトリのクローンを作成してローカルコピーを作成します。

VSOでプロジェクトのメインページに移動し、[Visual Studioで開く]をクリックします。



Visual StudioはVSOプロジェクトへの接続を開きます。

[チームエクスプローラー]ウィンドウで、ローカルリポジトリのアドレスを入力し、[クローン]ボタンをクリックします。



「新規」をクリックして、新しいソリューションを作成します。



ASP.NET Webアプリケーションプロジェクトテンプレートを選択し、プロジェクト名を指定して[OK]をクリックします。



ASP.NET 5 Preview Web Applicationテンプレートを選択し、「OK」をクリックします。



次に、単体テストを含むプロジェクトを追加します。 ソリューションエクスプローラーでソリューションを右クリックし、[新しいプロジェクトの追加]を選択して、単体テストプロジェクトテンプレートを選択します。 私のプロジェクトはCITest.Testsと呼ばれます。

解決策は次のとおりです。



UnitTest1クラスは、唯一のTestMethod1メソッドで作成されました。 TestMethod1には実装がないため、合格します。

式Assert.Failを使用して、2番目のTestMethod2メソッドを追加します。 2番目の方法は完了せず、テストランナーが必要なテストを正常に識別して実行したことを示すだけです。

using System; using Microsoft.VisualStudio.TestTools.UnitTesting; namespace CITest.Tests { [TestClass] public class UnitTest1 { [TestMethod] public void TestMethod1() { } [TestMethod] public void TestMethod2() { Assert.Fail("failing a test"); } } } 

変更を保存し、アセンブリを実行します。

ここで、コミットをローカルリポジトリにコミットし、ローカルからリモートに送信する必要があります。 これを行うには、チームエクスプローラーウィンドウの[変更]タブに移動し、コミットにコメントを追加して、[コミットとプッシュ]オプションを選択します。



リモートGitリポジトリのmasterブランチには、Webアプリケーションとテスト付きのプロジェクトを含むソリューションが含まれるようになりました。

ビルドプロセス定義の作成

次に、VSOでビルド定義を作成します。

チームが作業するプロジェクトの「ビルド」ページに移動し、「+」ボタンをクリックします。



Visual Studioテンプレートを選択し、[OK]をクリックします。



アセンブリを定義するVisual Studioテンプレートには、4つのアセンブリステップが含まれています。

1. Visual Studioビルド-ソリューションビルド
2. Visual Studio Test-テストの実行
3. ソースのインデックス作成とシンボルの公開-.pdbファイルでのソースコードのインデックス作成とシンボルの公開
4. ビルドアーティファクトの公開-アセンブリアーティファクト（dll、pdb、およびxmlドキュメントファイル）を公開します

デフォルトのままで、「保存」をクリックして、作成した定義の名前を指定します。



テストするには、「キュービルド」をクリックします。



デフォルト設定を受け入れて、「OK」をクリックします。



ビルドプロセスのブラウザに入ります（BUILD-> Explorer）。 アセンブリはキューに入れられ、プロセスが開始されるとすぐに、出力ウィンドウにこれに関する情報が表示されます。



ビルドは、ソリューションのビルドステップで次のエラーで失敗しました-Dnxランタイムパッケージをインストールする必要があります。

このエラーの理由は、リモートサーバー上でビルドプロセスを開始し、適切なDNX環境をインストールする必要があるためです。DNX環境は、このソリューションでアセンブリ用に選択されます。

Visual Studioに戻って、新しいファイルをソリューションに追加しましょう。 Prebuild.ps1を呼び出して、次のPowershellスクリプトを追加します。

 DownloadString('https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.ps1'))} # load up the global.json so we can find the DNX version $globalJson = Get-Content -Path $PSScriptRoot\global.json -Raw -ErrorAction Ignore | ConvertFrom-Json -ErrorAction Ignore if($globalJson) { $dnxVersion = $globalJson.sdk.version } else { Write-Warning "Unable to locate global.json to determine using 'latest'" $dnxVersion = "latest" } # install DNX # only installs the default (x86, clr) runtime of the framework. # If you need additional architectures or runtimes you should add additional calls # ex: & $env:USERPROFILE\.dnx\bin\dnvm install $dnxVersion -r coreclr & $env:USERPROFILE\.dnx\bin\dnvm install $dnxVersion -Persistent # run DNU restore on all project.json files in the src folder including 2>1 to redirect stderr to stdout for badly behaved tools Get-ChildItem -Path $PSScriptRoot\src -Filter project.json -Recurse | ForEach-Object { & dnu restore $_.FullName 2>1 } 

スクリプトはDNVMを起動し、 グローバルファイルからDNXのバージョンを決定します。 ソリューションのjsonは 、DNXをインストールし、project.jsonファイルに含まれるプロジェクトの依存関係を復元します。

Prebuild.ps1ファイルを追加すると、ソリューションは次のようになります。



変更をローカルリポジトリにコミットし、リモートリポジトリに送信します。

ここで、Powershellスクリプトステップをアセンブリ定義に追加する必要があります。
VSOに戻り、ビルド手順を編集しましょう。 「+」をクリックして、Powershellステップを追加します。



Powershellスクリプトを使用してタスクをビルドステップのリストの先頭に移動して、最初に開始するようにしましょう。 「スクリプト」をクリックして、ファイルPrebuild.ps1を選択します。 [保存]をクリックしてから[キュービルド]をクリックしてテストします。



これで、すべてのアセンブリ手順が正常に完了しました。



それでも、テストステップの結果をより詳細に調べることにした場合、警告が表示されます-公開する結果が見つかりません。 しかし、2つのメソッドをソリューションに追加しました。

答えは、次の「実行」式に含まれています。これは、vstest.consoleが2つのテストファイル、つまりCITest.Tests.dllに対して実行されたことを示しています。 そして、Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll、これは悪いです。



UnitTestFramework.dllファイルを除外するには、テストのビルドステップを変更する必要があります

アセンブリ定義を編集し、テストステップを選択して、テストアセンブリパスを現在の** \ $（BuildConfiguration）\ * test * .dll;-：** \ obj \ **から次の** \ $（BuildConfiguration）\ *テストに変更します。 dll;-：** \ obj \ **。

[保存]と[キュービルド]をクリックします。



アセンブリに失敗しました。 しかし、これはまさに私たちが目指していたものです。 TestMethod2には式Assert.Fail（）が含まれているため、スクリーンショットでわかるように、テストステップの失敗を引き起こしました。 この失敗により、テストが正しく実行されることを証明しました。

継続的インテグレーションの構成、アーティファクトのアセンブリおよび展開のトリガー

アセンブリの定義には、DNXをダウンロードする予備ステップがあり、次にソリューションアセンブリを提供するステップと、TestMethod2メソッドのおかげで失敗するテストステップがあります。

次は、継続的インテグレーションを設定し、UnitTest1クラスを変更します。 次に、変更をコミットしてリポジトリに送信します。これは、アセンブリを開始するトリガーとして機能します。

アセンブリ定義を編集して、「トリガー」タブに移動します。 継続的インテグレーション（CI）を選択し、「保存」をクリックします。



Visual StudioでUnitTest1.csファイルを編集し、TestMethod2メソッドを削除します。 次に、変更をコミットして送信します。

VSOに戻ってBUILDページに行きましょう。 [キュー]リストに、起動待ちのアセンブリが表示されます。



すべてのステップが正常に完了しました。

DNXは、アセンブリが実行されているリモートホストに正常にインストールされました。 決定がまとめられました。 すべてのテストが実行中です。 文字ファイルが生成されます。 最後に、アセンブリ成果物が公開されます。

つまり、アプリケーションの新しいテスト済みアセンブリが用意されています。

ビルドアーティファクトをWebアプリケーションサーバーに展開する

WebアプリケーションをAzureでホストする場合、Azure Web Application Deploymentステップをビルドプロセス定義に追加する必要があります。この場合、アプリケーションが正常にビルドおよびテストされると、ビルドアーティファクトがAzureに自動的にデプロイされます。

または、アセンブリアーティファクトを手動でダウンロードしてから、目的のサーバーにコピーすることもできます。 これを行うには、完成したアセンブリのリストに移動し、必要なアセンブリを開く必要があります。 次に、[成果物]タブを選択し、[ダウンロード]をクリックします。 結果の.zipファイルには、必要なファイルが含まれます。

テスト

それで、ウェブサイトがあります。 それをテストする方法を見てみましょう。

ビルド定義を実行する準備として、ビルドエージェントを準備することを意味します。 このリンクには、アセンブリエージェントを構成するための手順が記載されています。

ビルドプロセス定義を作成し、Visual Studioテンプレートを選択します。



Visual Studioテンプレートを選択すると、ビルドタスクとユニットテスクタスクが自動的に追加されます。 次に、各タスクに必要なパラメーターを入力します。 ビルドタスクは、ビルドする必要がある決定と構成オプションを取ります。 前述のように、このソリューションには、アセンブリ検証の段階の1つとして、実行するアプリケーションコード、単体テスト用コード、および実行する自動Seleniumテストが含まれています。



最後に、単体テスト-アセンブリのテストタスクに必要な必須パラメーターとフィルターのテスト条件を追加します。 このタスクでは、ユニットテストのdllを取得し、すべてのテストを列挙して自動的に実行することに注意してください。 特定のテストを実行する必要がある場合は、テストフィルター条件を有効にし、テストセットの種類ごとにフィルターを使用できます。 もう1つの重要な点は、Visual Studioテストタスクのユニットテストは、アセンブリが行われるサーバーで常に実行され、展開のために追加の設定を必要としないことです。

テスト管理にVisual Studio Onlineを使用する

仮想マシンを構成してアプリケーションをデプロイし、テストを実行します

アセンブリが完了して単体テストに合格したら、次のステップはアプリケーション（Webサイト）をデプロイし、機能テストを実行することです。

これを行うには、次のコンポーネントが必要です。

1. IISがインストールされ、WebサイトまたはMicrosoft Azure Webサイトを展開する準備ができて構成されたWindows Server 2012 R2。
2. これらのマシンでSeleniumテストを自動的に実行するためのブラウザー（Chrome、Firefox、およびIE）がインストールされた仮想マシンのセット。

これらの仮想マシンがPowershellを介したリモートアクセスで構成されていることを確認する必要があります 。

仮想マシンの準備ができたら、テストハブ->マシンページに移動して、スクリーンショットに示すように必要な構成を作成します。 仮想マシンのグループの名前と、仮想マシンのIIS / WebサーバーのFQDN / IPアドレスを指定します。 また、将来の設定のために管理者ログインとパスワードを入力する必要があります。



テスト環境では、名前を指定し、必要なブラウザーで既に構成されているマシンのすべてのIPアドレスを追加します。 前述のように、自動テストシステムはすべてのテストの分散実行が可能であり、異なる数の仮想マシンに拡張できます。

その結果、仮想マシンのハブでは、テスト環境とテスト環境自体に1つのアプリケーションが存在します。たとえば、この例では、それぞれ「テスト中のアプリケーション」と「テストマシン」です。

アプリケーションの展開とテストの設定

次に、Webサーバーにアプリケーションをデプロイするタスクと、仮想マシンでリモートで統合テストを実行するタスクを追加します。

新しい手順を追加して継続的な展開を実装するだけで、同じアセンブリ定義を使用します。

Powershellを使用したWebサイトの展開

最初に、すべてのWebサイトファイルを目的の場所にコピーします。 「ビルドステップの追加」をクリックし、「Windows Machine File Copy」タスクを追加して、ファイルをコピーするためのパラメーターを入力します。 次に、「ターゲットマシンでPowershellを実行タスク」をアプリケーション環境の展開/構成の定義に追加します。 WebサーバーにWebアプリケーションをデプロイするには、「テスト対象のアプリケーション」を選択します。仮想マシンのグループとして、以前に構成しました。 Webサイトの展開にPowershellタスクを選択します。 このスクリプトがソリューション/プロジェクトに含まれていることを確認してください。 このタスクは、リモートマシンでPowershellスクリプトを実行して、Webサイトおよびその他の追加手順を構成します。

テスト環境へのテストのコピー

「ファイルのコピー」タスクをアセンブリ定義に追加して、すべてのテストファイルを「Test Machines」グループにコピーします。

任意の場所を選択できます。例では「C：\ Tests」を使用します

Visual Studioテストエージェントのセットアップ

リモートマシンでアクションを実行するには、最初にテストエージェントを作成および構成する必要があります。 これを行うには、リモートマシンに関する情報を書き込むタスクを作成します。

Visual Studioの以前のバージョンとは異なり、テスト環境のコンピューターでコントローラーとテストエージェントを手動でコピーして構成する必要はありません。

リモート仮想マシンでテストを実行する

セットアップが完了したら、最後のタスクは「テストエージェントを使用してVisual Studioテストを実行する」を追加してテストを実行することです。 このタスクでは、テストアセンブリの情報とテストを実行するためのフィルターを指定します。 アセンブリ検証の一部として、P0 Seleniumテストを実行するため、テストアセンブリとしてSeleniumTests * .dllを使用してアセンブリをフィルタリングする必要があります。

入力として、テストおよびテスト実行パラメーターを含むrunsettingsファイルを含めることができます。 以下に、$（addurl）変数を使用して、アプリケーションがデプロイされた場所に関するテストのデータを示します。



タスクを追加して構成したら、ビルドプロセス定義を保存する必要があります。

アセンブリのキューイング、テストの実行、テスト結果の分析。

アセンブリプロセスの定義ですべてのタスクのセットが準備できたので、アセンブリをキューに配置することから開始できます。 その前に、ビルドサーバーとテストマシンのプールが正しく構成されていることを確認する必要があります。

アセンブリが完了すると、VSOは、その後の意思決定に必要なすべての情報とともに、アセンブリ結果の概要を提供します。

ビルド結果には次の情報が含まれます。

• ステップの結果と、パネルの左側の色で強調表示されている部分、および右側の詳細。
• 各ステップをクリックすると、詳細なログエントリが利用できます。
• テスト結果から、すべての単体テストに合格したことがわかりますが、統合テストには問題があります。

「テスト結果」をクリックすると、テスト実行結果に移動できます。

テスト実行ページには、結果のより深い研究のための一連のグラフとメカニズムが含まれています。



「テスト結果」に切り替えると、各テストの情報（テストの名前、テストのパラメーター、作成者、実行された仮想マシンなど）も表示できます。

失敗したテストごとに、「分析の更新」オプションを使用して分析できます。 次のスクリーンショットは、IE Seleniumテストが失敗したことを示しています。 [バグの作成]をクリックすると、作成された要素にすべてのテスト情報が自動的に追加されます。

継続的統合の設定

すべてのテストが検査され、欠陥が登録されたので、アセンブリプロセスの定義を構成して、チェックインごとに連続統合プロセス、単体テスト、統合テストを自動的に開始できます。

構成するには2つの方法があります。

• 「継続的統合」を選択して、各チェックのプロセスを開始します。
• 特別なスケジュールされた起動を選択して、すべての変更が行われた後に確認します。

スクリーンショットに示すように、両方のオプションを選択できます。



したがって、アセンブリプロセスの同様の定義を使用して、アセンブリを自動的に起動し、単体テストを実行してアセンブリを検証するように継続的統合プロセスを構成することができました。

おわりに

最終的に、Visual Studio Onlineの助けを借りて、いくつかの問題を解決することができました。

1. 単体テストと自動テストを含む簡単なビルドプロセス定義を作成する
2. テスト環境とテストエージェントをセットアップする
3. アセンブリの結果とテストの開始に関するレポートを取得しました
4. 継続的な統合アプローチを使用してビルドプロセスをカスタマイズしました

便利なリンク

• ビデオコンテンツ： Visual Studioを使用した 継続的な統合とDevOps
• Visual Studio Online： 公式サイトとドキュメント
• Visual Studio 2015： 無料の開発者向け製品