ステップ 7 ハンズオン 「Visual Studio 2005 Team System によるアプリケーション品質の向上」

第 5 回 チーム開発を支える機能 - その 2

チーム ビルドとレポート機能

NRI ラーニングネットワーク
矢嶋　聡

最終更新日 2007 年 10 月 31 日

チーム ビルドとレポート機能

ここでは、Visual Studio Team System が提供するソフトウェア構成管理機能 (注意 1) のうち、ソースコードの一括ビルドを自動化する ”チームビルド” と、各活動の統計分析を支援する ”レポート機能” について取り上げます。特に、チームビルドは単なるビルドの自動化に留まらず、作業項目やソース管理と連携し、時系列に管理可能なビルド レポートを生成できる点についても確認します。また、チーム プロジェクトの活動を表す作業項目が、活動の統計情報であるレポートに対して、どう関係するかを確認します。

注意 1: ソフトウェア構成管理とは、ソフトウェア システムの各種構成項目について、ソフトウェア システムのライフ サイクルを通して行われる追跡や変更、検証などの管理作業の総称です。

図 1. チーム ビルドとレポート機能

今回のステップ 7 は、前回のステップ 7 (チーム開発を支える機能 - その 1 : 作業項目と連携したソース管理) で作成したチーム プロジェクト OurTeam1 を引き続き使用します。よって、マシン環境としては、前回のステップ 7 と同様に、サーバーとして、Visual Studio 2005 Team Foundation Server を用意する必要があります (注意 2)。また、クライアントとして Visual Studio 2005 から、 Team Foundation Server にアクセスするには、Visual Studio 2005 チーム エクスプローラを追加インストールする必要があります (注意 3)。

さらに、今回のステップ 7 で取り上げる ”チーム ビルド”　を行うには、ビルド用のマシン ”ビルド コンピュータ” を構成する必要があり、そのためには、 ”Team Foundation ビルド” をインストールしなければなりません (注意 4)。

注意 2: Team Foundation Server のインストールや環境構成方法は、インストール媒体に含まれる ”インストール ガイド” に記載されています。

注意 3: Visual Studio 2005 チーム エクスプローラのインストール プログラムは、Team Foundation Server のインストール媒体に含まれます。チーム エスクプローラは Visual Studio 2005 Professional Edition や Standard Edition に対してもインストールできます (ただし、CAL（クライアント アクセス ライセンス）を購入いただく必要があります)。詳しくは、http://msdn2.microsoft.com/ja-jp/library/ms316479(VS.80).aspx (Visual Studio Team System クライアント計画) を参照してください。

注意 4: Team Foundation ビルドのインストール プログラムは、Team Foundation Server のインストール媒体の \build フォルダにあります。インストール要件や環境構成方法は、Team Foundation Server のインストール ガイドに記載されています。Team Foundation ビルドは、Windows Server 2003 SP1 だけでなく、Windows XP SP2　にもインストールすることができます。なお、チーム ビルドを行う際に、テストも同時に行うことができますが、そのためには、Team Foundation ビルドをインストールしたマシンに、テスト機能を持つエディションの Visual Studio 2005 がインストールされていなければなりません。今回は簡単にするため、チーム ビルドの際に、テストは行いません。

このステップでは、チーム ビルドを行うための定義ファイルとも言える　”チーム ビルドの種類” を作成します。これを行うために、前回のステップ 7 である ”チーム開発を支える機能 - その 1 : 作業項目と連携したソース管理” で作成したチーム プロジェクト OurTeam1 を引き続き使用し、このチーム プロジェクトのソース管理下にある ClassLibrary1 ソリューションを対象にします。まず、前回のステップ7でチーム プロジェクトを作成したユーザー アカウントを使用して、クライアント マシンにログオン (注意 5) を行い、Visual Studio 2005 を起動してください。

注意 5: ”チーム ビルド” の種類を作成する際に使用するユーザー アカウントは、このチーム プロジェクトに対して、 ”ビルドを管理します” というアクセス許可が必要です。さらに、ソース管理に関して、 ”チェックイン” と ”チェックアウト” のアクセス許可が必要です。前回のステップ 7 で使用したユーザー アカウント (この説明では Taro) は、このチーム プロジェクトを作成したので、チーム プロジェクト単位のユーザー グループである ”Project Administrators” に既定で所属しています。そのため、これらのアクセス許可をすべて保持しており、 ”チーム ビルドの種類” を作成することができます。

Visual Studio 2005 から Team Foundation Server に接続していなければ、前回のステップ 7 の Step 1 の手順に従って、Team Foundation Server に接続します。

チーム ビルドの種類を作成するため、メニューより [ ビルド ] - [ 新しいチーム ビルドの種類 ] の順に選択して、 [ 新しいチーム ビルドの種類の作成ウィザード ] を起動させます。”新しいチーム ビルドの種類の作成ウィザードへようこそ” という見出しのページが開いたら、次図のように、 ”チーム ビルドの種類の名前” として、 ”OurBuild1” と入力し、説明欄には適当な説明文を追加します。

図 2 . [ 新しいチーム ビルドの種類の作成ウィザード ]

[ 次へ ] ボタンをクリックします。

”ビルドするソリューションの選択および順番指定” という見出しのページが表示されるので、このチーム　プロジェクトに既に含まれるソリューション ”ClassLibrary1” を、次図のようにチェックします。

図 3 . ソリューション ”ClassLibrary1” を選択

[ 次へ ] ボタンをクリックします。

”ビルドする構成の選択” という見出しのページが次図のように表示されるので、既定のまま ( ”Release” を構成として選択したまま) にして、　[ 次へ ] ボタンをクリックします。

図 4. ビルド構成の選択

”ビルドの場所” という見出しのページが表示されるので、次図のように、順に、ビルド コンピュータ名、そのコンピータの作業用の ”ビルド ディレクトリ”、そして、ビルドによって出力されたファイルの ”格納場所” を指定します (注意 6) 。この例では、順に "srv100xp2" 、 "C:\Build" 、 "\\srv100xp\Dist" を順に指定しています。

注意 6: チーム ビルドの実行には、専用のユーザー アカウントが利用されます (Team Foundation ビルドのインストール時に指定したアカウント、 ”インストール ガイド” では TFSSERVICE) 。このアカウントは、ビルド ディレクトリや格納場所に対して、ビルド作業での書き込み操作が出来る必要があります。(NTFS セキュリティでの ”変更” アクセス許可、共有フォルダでの ”フルコントロール” )

図 5. ビルド作業の場所と出力先の指定

[ 次へ ] ボタンをクリックします。

”ビルド オプションの選択” という見出しのページが表示されるので、このページは既定のまま、テストの実行やコード分析を行わず、　[ 次へ ] ボタンをクリックします。

図 6. テストやコード分析の指定

”ビルドの種類の選択の確認” という見出しのページが表示され、今までの設定内容が提示されるので、設定項目を確認します。このページの下部に示されているように、”ビルドの種類” のためのファイルは、ソース管理下にチェックインされることが分かります。

図 7. チーム ビルドの種類の各選択のサマリー

確認が済んだら、 [ 完了 ] ボタンをクリックして、チーム ビルドの種類を作成します。

作成処理が終わると、チーム エクスプローラには、 次図のように [ チーム ビルド ] ノードの下に、今作成したチーム ビルドの種類を表すノード [ OurBuild1 ] が追加されます。

図 8. チーム ビルドの種類を表すノード

また、Visual Studio 上には、チーム ビルドの種類の定義ファイルである .proj ファイルが自動的に開きます。これは、ソース管理下にチェックインされた定義ファイルの一時的なコピーです。ここでは、閉じておきます。(次のステップでは、このファイルを編集可能な状態で開く方法を確認します。)

このステップでは、前のステップで作成したチーム ビルドの種類の定義ファイルを、編集可能な状態で開く方法を確認します。この定義ファイルは、ソース管理下に置かれるので、編集する際には、チェックアウトしなければなりません。

メニューより [ 表示 ] - [ その他のウィンドウ ] - [ ソース管理エクスプローラ ] の順に選択して、 ソース管理エクスプローラを開きます。 ソース管理エクスプローラの左ペインのツリーで、 [　OurTeam1 ] ノード、 [ TeamBuildTypes ] ノードの順に展開し、次図のように [ OurBuild1 ] ノードを選択します。右ペインには、このノード (このフォルダ) に含まれるファイルの一覧が表示されます。

図 9. ソース管理下のチーム ビルドの種類

ここで左ペインの、 ”OurBuild1” ノード　(フォルダ) を右クリックして、 [ 最新バージョンの取得 ] をクリックします。

今のところ、チェックアウトする際に、このソース管理下のファイルをローカル フォルダへマッピングするための定義がワークスペース上にないので、チェックアウト先のローカル フォルダをマッピングすべく、次図のように [ フォルダの参照 ] ダイアログボックスが開きます。

図 10. チェックアウト先のローカル フォルダの選択

適当な場所を選択します。(ここの説明では、C:\work を選択することにします。必要に応じて、このダイアログボックスの左下にある [ 新しいフォルダの作成 ] ボタンを利用して、フォルダを作成してください。)

場所を選択したら、 [ OK ] をクリックします。

これで、ソース管理フォルダとローカル フォルダのマッピングが済み、同時に、チェックイン状態のままの、 ”OurBuild1” フォルダのローカルコピーが作られました。

参考: ワークスペースのマッピングの設定を確認するには、メニューより [ ファイル ] - [ ソース管理 ] - [ ワークスペース ] を選択し、[ ワークスペースの管理 ] ダイアログボックスを表示させます。さらに、このダイアログボックスで特定のワークスペースを選択し (既定では 1 つしかありません)、 [ 編集 ] ボタンをクリックすると、 ワークスペースの編集ダイアログボックスが表示され、どのようなマッピングがされたか、確認できます。

図 11. ソース管理フォルダ $/OurTeam1 とローカルフォルダ C:\work のマッピング

再び、ソース管理エクスプローラ上の左ペインで ”OurBuild1” フォルダを右クリックし、 [ 編集用にチェックアウト ] をクリックします。

[ チェックアウト ] ダイアログボックスが表示されたら、既定の設定のまま、 [ チェックアウト ] ボタンをクリックします。

チェックアウトの状態になり、ソース管理エクスプローラの表示では、次図のように ”OurBuild1” フォルダ内の、各ファイル名の先頭にはチェックマークが付き、チェックアウトの状態になります。

図 12. ”TFSBuild.proj” のチェックアウト

さらに、ソース管理エクスプローラ上で ”TFSBuild.proj” をダブルクリックして開きます。先に構成されたワークスペースのマッピングの定義に基づいて、ローカル フォルダの ”TFSBuild.proj” が編集可能な状態で開きます。

図 13. 編集可能な ”TFSBuild.proj”

このファイル内のコメントに目を通して、各 XML 要素で何を定義しているのか、ざっと確認します。この定義ファイルは、前述のウィザードを使用すると、対話形式で簡単に作成できますが、このテキスト エディタを使用して、あとから、きめ細かく修正することもできます。

確認が済んだら、 ”TFSBuild.proj” を閉じておきます。

ここでは、編集をしなかったので、チェックアウトをキャンセルすることにします。まず、ソース管理エクスプローラの左ペインで ”OurBuild1” フォルダを右クリックし、 [ 保留中の変更を元に戻す ] をクリックします。(もし、変更してチェックインしたいのならば、 [ 保留中の変更をチェックイン ] を選択します。

[ 保留中の変更を元に戻す ] ダイアログボックスが表示されたら、 [ 変更を元に戻す ] ボタンをクリックします。

これで、ソース管理下にチェックインされた状態になりました。

次に、チーム ビルドを実際に行ってみます。

チーム エクスプローラ上の [ チーム ビルド ] ノードの配下にある [ OurBuild1 ] ノードを右クリックして、 [ チーム　プロジェクトのビルド ] をクリックします。

次図のように、 [ ビルド ”OurTeam1” ] ダイアログボックスが表示されるので、設定内容に間違いがないか確認した後、 [ ビルド ] ボタンをクリックして、チーム ビルドを開始します。

図 14. チーム ビルドの開始を行うダイアログボックス

すると、次図のように進行状況を示すウィンドウが表示されます。

図 15. チーム ビルドの進行状況を表すウィンドウ

チーム ビルドが終了したら (上部に緑色のアイコンと ”正常終了” という文字が表示されたら)、このウィンドウをスクロールして、内容を確認します。(このウィンドウは、まだ閉じないでください。)

参考:　前述のチームビルドの実行結果のウィンドウを、うっかり閉じてしまった場合は、チーム エクスプローラ上の [OurBuild1] ノードをダブルクリックして、次図のようなチーム ビルドの実行結果のサマリーのウィンドウを、まず開いてください。このサマリーは、チームビルドを 1 回行うごとに、1 行ずつ増えていきます (現時点では、1 行だけあるはずです)。この一覧の最初の 1 行目をダブルクリックすると、前述の実行結果のウィンドウを開くことができます。

図 16. チーム ビルドの実行結果のサマリー

ここで、チーム ビルドの実行結果のウィンドウの下部で、 [ 関連付けられた変更セット ] というタイトルのセクションと、 [ 関連付けられた作業項目の ] というタイトルのセクションを見つけ、それぞれの先頭の [+] ハンドルをクリックして、各セクションを展開します (次図参照) 。

図 17. 関連付けられた変更セットと作業項目

このウィンドウに表示された変更セットは、前回のチーム ビルドの実行から、今回のチーム ビルドの実行の間に行われた変更差分の一覧であり、チーム ビルドの対象になった、ClassLibrary1 ソリューションに関する変更セットです。また、この変更セットに関連付けられた、作業項目も表示されます。今回は、チーム ビルドの初回の実行なので、ClassLibrary1 ソリューションに関するすべての変更セットと作業項目が一覧表示されます。

このような履歴があると、チーム ビルドでビルド エラーが発生した場合、前回の正常終了したビルドと今回のビルドとの間で行われた変更差分を、容易に把握できるので、エラー原因の追及を効率よく行うことができます。

確認が済んだら、チーム ビルドの実行結果のウィンドウを閉じておきます。

この後は、再び ClassLibrary1 ソリューションのソースコードを変更し、再度チーム ビルドを行い、チームビルドの実行結果に、変更差分だけが履歴としてどう反映されるか確認します。

このステップでは、前回のステップ 7 で作成した ClassLibrary1 ソリューションのソースコードを再び変更します。

まずは、以降の手順に従ってチェックアウトします (手順は前回のステップ 7 で行ったものと同様です)。

メニューより [ 表示 ] - [ その他のウィンドウ ] - [ ソース管理エクスプローラ ] の順に選択して、 ソース管理エクスプローラを開きます。

左ペインのツリーで、 [ OurTeam1 ]　ノードの下にある [ ClassLibrary1 ] フォルダをクリックして選択します。

右ペインで、ClassLibrary1.sln を見つけ (次図参照)、これをダブルクリックして、このソリューションを開きます。(結果的にローカル フォルダのソリューションが開くので、 [ ファイル ] メニューから明示的にローカル フォルダのソリューションを開いても同じことになります。)

図 18. ソース管理下のソリューション ”ClassLibrary1.sln”

このソリューションは、まだチェックインの状態なので (ソリューション エクスプローラ上の各ファイルには、錠前アイコンが付いています)、ソリューション エクスプローラの最上位のノードであるソリューションを右クリックして、ショートカット メニューから [ 編集用にチェックアウト ] をクリックします。

[ チェックアウト ] ダイアログ ボックスが表示されたら、既定の設定のまま、 [ チェックアウト ] ボタンをクリックします。

ソリューション エクスプローラ上で、ファイル ”Class1.cs” をダブルクリックして、このファイルのコード エディタを開きます。

Class1 クラスに、次のように Proc1 メソッド を追加します (入力するのは、赤色の部分)。

namespace ClassLibrary1
{
    public class Class1
    {
        public int Add(int a, int b)
        {
            return (a + b);
        }
        public int Proc1()
        {	
            return 0;
        }
    }
}

入力が済んだら、 [ ファイル ] - [ Class1.cs の保存 ] を選択して、ファイルを保存します。これは、ローカル フォルダにおける保存です。 Class1.cs を閉じておきます。

次に、チェックインを行います。まず、メニューより [ 表示 ] - [ その他のウィンドウ ] - [ 保留中の変更 ] の順に選択して、[ 保留中の変更 ] ウィンドウを開きます。

[ 保留中の変更 ] ウィンドウの左端に縦に並んだボタンのうち、一番上のボタンをクリックして、コメント欄を表示させ、次図のようにコメントとして、 ”さらに Proc1 メソッドを追加” と入力します。

図 19. コメントの入力

[ 保留中の変更 ] ウィンドウの左端に縦に並んだボタンのうち、上から 2 番目のボタンをクリックします。次図のように、作業項目の一覧が表示されるので、適当な作業項目 (たとえば、 ”ソースコードの移行”、ここでは操作を確認する練習なので、どの作業項目でもかいません) を見つけ、先頭のチェックボックスにチェックマークを付け、右端の [チェックイン動作] 列では、ドロップダウンリストから ”関連付け” を選択します。

図 20. 作業項目のチェックイン動作で、”関連付け” を選択

[ 保留中の変更 ] ウィンドウの左上部にある [ チェックイン ] ボタンをクリックします。

[ 保留中の変更 ] ウィンドウを閉じます。

メニューより、 [ ファイル ] - [ ソリューションを閉じる ] の順に選択し、Class1Library ソリューションを閉じておきます。

このステップでは、変更後のソースコードに対して、再びチーム ビルドを実行して、実行結果にどのような履歴が出力されるか確認します。

チーム エクスプローラ上の [ チーム ビルド ] ノードの配下にある [ OurBuild1 ] ノードを右クリックして、 [ チーム　プロジェクトのビルド ] をクリックします。

[ ビルド ”OurTeam1” ] ダイアログボックスが表示されるので、設定内容に間違いがないか確認した後、 [ ビルド ] ボタンをクリックして、チーム ビルドを開始します。

チーム ビルドの実行状況を表示するウィンドウが開いて、チーム ビルドが終了したら (上部に緑色のアイコンと ”正常終了” という文字が表示されたら)、このウィンドウをスクロールして、内容を確認します。(このウィンドウは、まだ閉じないでください。)

ここで、チーム ビルドの実行結果のウィンドウの下部で、 [ 関連付けられた変更セット ] というタイトルのセクションと、 [ 関連付けられた作業項目の ] というタイトルのセクションを見つけ、それぞれの先頭の [+] ハンドルをクリックして、各セクションを展開します (次図参照) 。

図 21. 変更差分のみの変更セットと作業項目

今度の関連付けられた変更セットは、前回のビルド以降に行われた分だけです。Proc1 メソッドを追加した変更セットのみ (差分) が、一覧に表示されます。また、関連付けられた作業項目も、変更差分に関連付いた作業項目だけが一覧表示されます。

このようにチーム ビルドでは、一定間隔で (たとえば日ごとに) 継続的にチーム ビルドを実行すると、前回のチーム ビルド以降に行われた変更や関連する作業項目を、簡単に追跡することができます。

ここで、関連付けられた作業項目 (コメントが ”さらに Proc1 メソッドを追加” のもの) の先頭にあるリンクをクリックして、この変更セットの詳細を表示します。

次図に示すように、今回のソースコードの変更作業では、変更されたファイルが ”Class1.cs” だけであることが分かります。

図 22. 変更セットの詳細

ここで、この変更セットの詳細ウィンドウに表示された、 ”Class1.cs” を右クリックし、ショートカット メニューより、 [ 比較 ] - [ 以前のバージョンとの差異 ] をクリックします。

すると、次図のように、[ 相違点 ] ダイアログボックスが表示され、一つ前のチェックインから後に行われた変更差分を確認することができます。より新しいバージョンである右半分のウィンドウでは、Proc1 メソッドが追加されています。今回のチーム ビルドでは、関連付けられた変更セットはこの 1 つだけなので、ここに表示された差異は、実質的に前回のチーム ビルド以降に行われた変更差分になります。前回のチーム ビルド以降に、Proc1 メソッドが追加されていることが分かります。

図 23. 変更差分の確認

このような Team Foundation Server が提供するチーム ビルドを日々継続的に利用すると、時系列的に、ソースコードの修正を追跡することができるようになります。

確認が済んだら、[ 相違点 ]　ダイアログボックスを閉じておきます。

また、変更セットの詳細のウィンドウや、チームビルドの実行結果のウィンドウも閉じておきます。

残りの 2 つのステップでは、 ”レポート機能” について確認します。特に、チーム プロジェクトの活動を表す作業項目が、活動の統計情報であるレポートに対して、どう関係するかを確認します。

まず、このステップでは、日々のテスティングやチームビルドの過程で、バグが発見された際に行う、バグ報告を作成します。バグ報告も、作業項目として作成され、特定の担当者が対応することになります。今回の一連のサンプルでは、ビルド エラーやバグが実際にあるわけではありませんが、チームビルドの過程で、バグが発見されたと仮定して、バグ (という種類の作業項目) を作成します。

メニューより、 [ チーム ] - [ 作業項目の追加 ] - [ バグ ] の順に選択し、次図のように新規作成のウィンドウを開いて、タイトルに ”Class1.Add メソッドの誤動作” と入力し、下半分の [ 説明 ] タブには、適当な説明文を入力します。その他は、既定のままにします。

図 24. バグ (作業項目) の入力

メニューより [ ファイル ] - [ 新しいバグ 1 の保存 ] の順に選択して、この作業項目を保存しておきます。(この作業項目は、Team Foundation Server 上に保存され、バグ1ではなく、適当な番号が割り振られます。)

保存が済んだら、バグ (作業項目) の編集画面を閉じておきます。

ここで、作業項目がサーバーに保存されたことを確認します。まず、チーム エクスプローラのツリー上で、 [ OurTeam1 ] ノード、 [ 作業項目 ] ノード、 [ チーム クエリ ] ノードの順に展開して、 [ チーム クエリ ] ノード内の [ すべての作業項目 ] をダブルクリックします。

次図のように、このチーム プロジェクト内のすべての作業項目が一覧表示されます。この中に、今保存した作成した ”Add メソッドの誤動作” というタイトルの作業項目 (バグ) があることを確認します。

図 25. 新規に追加したバグ (作業項目)

いったん、バグという作業項目として作成されれば、他の作業項目と同様に、チーム プロジェクトの中で、1 つの作業として追跡されることになります。もし、このバグに対処するために、ソースコードの変更を行った場合は、この作業項目と関連付けて、チェックインを行うことになります。これによって、この作業項目に関して、バグの対処として、どのようなソースコードの変更を行ったか、追跡することができます。また、このバグへの対処が済んだら、状態を ”終了” に変更することになります。

確認が済んだら、この画面を閉じておきます。

最後のステップでは、前のステップでバグ (作業項目) を作成したことによって、Team Foundation Server で管理されたレポートに、どのように影響するかを確認します。既定では、作業項目などのプロジェクトの活動情報に関して、1 時間ごとに自動的に集計され、SQL Server に保存されます。この情報は、SQL Server Reporting Services を使用して、レポート形式で表示するこができます。ここでは、強制的に集計を実行させ、その結果を確認します。

Team Foundation Server のインストール時に使用したアカウント (”インストール ガイド” では、TFSSETUP)　を使用して、Team Foundation Server のアプリケーション層のサーバー (この例は、srv100) にログオンします。

スタート メニューより、 [ スタート ] - [ すべてのプログラム ] - [ 管理ツール ] の順に選択し、[ インターネット インフォメーション サービス (IIS) マネージャ ] を起動します。

インターネット インフォメーション サービス (IIS) マネージャの左ペインのツリーで、[ Web サイト ]、 [ Team Foundation Server ]、[ Warehouse ]　の順に展開し、さらに [v1.0] ノードをクリックして選択し(次図参照)、右ペインに ”warehousecontroller.asmx” があることを確認します。これは、Team Foundation Server での集計を制御する ASP.NET Web サービスです。

図 26. 集計を管理する Web サービス

右ペインで、 ”warehousecontroller.asmx” を右クリックし、 [ 参照 ] をクリックします。次図のように、この Web サービスに関する説明ページが開きます。

図 27. 集計を管理する Web サービスの説明ページ

このページで [Run] リンクをクリックします。

次図のように、”Run” Web メソッドの詳細ページが表示されます。

図 28. 集計を実行する ”Run” Web メソッド

このページの [ 起動 ] ボタンをクリックして、 ”Run” Web メソッドを実行します。

すると、問題なく実行されれば、次図のように、true が返ります。(集計処理は、非同期で実行されるので、この戻り値は集計の指示に成功したことを意味するものであって、集計が完了したことを意味するものでありません。集計対象のデータ数が少なければ、1 分程度で終了します。)

図 29. 集計を実行する ”Run” Web メソッドの戻り値

参考: 図 27 の Web サービスの説明ページで、 [GetWarehouseStatus] リンクをクリックすると、集計の状況を確認できる Web メソッドの詳細ページが開きます。[ 起動 ] ボタンをクリックして、このメソッドを実行すると、現在の集計処理の状態が分かります。集計が終了していれば、戻り値は ”Idle” という値になっているはずです。

クライアント マシンの Visual Studio 2005 に戻ります。

チーム エクスプローラのツリー上で、 [ OurTeam1 ] ノード、 [ レポート ] ノードの順に展開して(次図参照)、 [ レポート ] ノード内の [ バグ率 ] をダブルクリックします。

図 30. Team Foundation Server が提供するレポート機能

すると、レポートが開き、バグ数の推移のグラフが表示されます (初回は、表示までに少し時間がかかるかも知れません)。 レポートの画面は大きいので、Visual Studio 2005 を全画面で表示するとよいでしょう (メニューより [ 表示 ] - [ 全画面表示 ] )。

これは、SQL Server Reporting Services を利用したレポートで、今回はバグ (作業項目) を 1 つ新規作成したので、アクティブなバグ数が 1 つだけ増加していることが分かります。

図 31. バグ数の推移

このような集計情報を利用することで、プロジェクト活動に関して時系列で大局的な傾向をつかむことができ、今後の品質管理対策などにも役立てることができます。

確認が済んだら、Visual Studio 2005 の全画面表示を解除します (メニューより [ 表示 ] - [ 全画面表示 ] )。

参考: レポートの上部には、URL が表示されています。この URL にアクセスすれば、Internet Explorer からも、レポートを確認することができます。

確認が済んだら、レポートを閉じておきます。