アジャイル開発

  • [アーティクル]

常時結合を可能にするための Team Foundation Server の拡張

Ben Waldron

この記事で取り上げる話題:

  • アジャイル開発手法
  • Visual Studio 2005 Team System と Team Foundation Server
  • チーム プロジェクトのセットアップ
  • Team Foundation Server の拡張

この記事で使用する技術:

  • Visual Studio 2005 Team System、Team Foundation Server

サンプルコードのダウンロード: TeamSystem.exe (173KB)
翻訳元: Extend Team Foundation Server To Enable Continuous Integration (英語)

目次

  1. アジャイル手法
  2. 常時結合
  3. Visual Studio 2005 Team System
  4. 単体テスト プロジェクト
  5. チーム プロジェクトの作成
  6. ビルド単体テストの作成
  7. ビルドの定義
  8. Team Foundation Server の拡張
  9. 作業項目の割り当て
  10. まとめ

多くの開発チームで、変更を管理し、ソフトウェアの品質を向上させるために、既に "アジャイル" な手法が採用されています。このような手法では、新機能の追加、バグの修正、およびコードのリファクタを行うたびに、常に、ソフトウェア製品を増分的にビルド、およびテストする、常時結合が勧められています。Visual Studio 2005 Team System、および Team Foundation Server によって、アジャイル開発、および常時統合のプロセスはどのように支援されるでしょうか。

この記事では、この質問に答えるため、Visual Studio 2005 Team System の新しい単体テスト機能を使用したテスト駆動開発 (TDD) など、アジャイルの概念を取り入れてサンプルのプロジェクトを作成します。このプロジェクトを完成させた後に、Team Foundation Server を使用してチーム プロジェクトを作成する方法を説明します。さらに、このテクノロジの拡張機能を使用して、コードをソース管理にチェックインするとアプリケーションがビルドされるような常時結合を実現するカスタム Web サービスを構築する方法も説明します。

1. アジャイル手法

アジャイル開発の概念を具体的に説明する前に、まず、アジャイル開発の歴史を再考し、どのような手法がアジャイルなのかを明らかにします。

1990 年代、ラショナル統一プロセス (RUP) などのプロセス重視開発モデルに代わる手段として、いくつかの手法が考案されました。優先事項が頻繁に変更される、ユーザーからのフィードバックは無視できない、といったソフトウェア開発の動的な性質は、プロセス重視のモデルでは表現できないと考える開発者もいました。多くの開発チームは、経験から、ソフトウェア プロジェクトの形、および規模はさまざまであり、重厚なソフトウェア手法が適合しない場合も多く、特により小規模で、動的な開発作業にはこれが合わないことがわかっていました。たとえば、計画重視のウォーターフローの手法では、変化の激しい開発環境には適切に対応することができません。

エクストリーム プログラミング、適応型ソフトウェア開発、ダイナミック システム開発手法 (DSDM) などの手法はすべて、プロジェクト管理者、および開発者が、品質を犠牲にすることなく、頻繁な変更に対応できるようにするために作成されました。今から考えると、これらの手法は、明らかに多くのテーマにおいて共通性があります。顧客からのフィードバックやビジネスの要求にすばやく対応できるようにすること、製品をどのように展開するかに関しては顧客の意見が強いと理解すること、開発イテレーションを短くすること、およびテストで全範囲を完全にカバーすることなどです。開発チームは、まずそれぞれの組織に最適な手法を選択し、その後、その手法に改良を重ね、進化させてきました。

2001 年、優れたソフトウェアの専門家が集まり、これらの手法の共通性を議論しました。ここで、適応型のソフトウェア開発の "5 つの手法" が集結することになります。これらのソフトウェアの専門家により、これらすべての手法の共通点を包含する用語として "アジャイル" が選択されました。

これ以来、アジャイル開発は進化を遂げ、それを支援するツールも作成されました。一方、開発チームにも利点がありました。NUnit のような単体テストツールが、開発プロセスの重要な部分となりました。同様に、常時結合は、アジャイル手法を完全には導入していない多くの開発チームでも、標準的に導入されるプラクティスとなっています。このトピックについての詳細は、"アジャイル開発の関連資料" を参照してください。

ページのトップへ

2. 常時結合

常時結合は、Martin Fowler がソフトウェア開発のベスト プラクティスとして提唱した、単純で強力な技法です。この技法は、アジャイル開発プロセスと簡単に適合します (Continuous Integration (英語) を参照してください)。常時結合では、日次的なビルドの概念をさらに進歩させて、ソフトウェア製品を、その一部が変更されるごとにビルドします。多くの場合、開発者がコード、あるいは構成の変更をソース管理にチェックインするたびに、1 つのビルドが作成されます。ビルドは、集中管理されるソース管理リポジトリからすべてのファイルを取得し、コンパイルされます。ビルドの状態が、その都度、開発者、およびテスタに通知されるので、ビルドの失敗はすぐに明らかになり、修正することができます。この方法の発展型として、チェックインを完了する前にビルドを実行する方法もあります。この方法では、不具合を引き起こすようなチェックインは、そのチェックイン自体が中断します。

エクストリーム プログラミングで特に重視されるのは、常時結合に自然に適合する、TDD (テスト駆動開発) です。TDD では、開発者がテスト ケース (通常は単体テスト) を作成し、そのテストによって実行されるコードを作成し、自動化されたテストを実行し、必要に応じてコードをリファクタすることが提唱されています。このテストを効果的に作成することにより、単体テストで製品の全体をカバーする十分なテストを提供できるようにします。これらの自動化されたテストは、すべての開発者、およびテスタがアクセスできる共通の場所に配置され、コードをビルドにチェックインする前に実行されます。

TDD が常時結合に適しているとされるのは、ビルドをコンパイルした後、その最新のビルドに対してすべての単体テストを実行するためです。単体テストが失敗した場合には、不具合があることになるのでビルドが失敗します。製品の品質を確実にするためには、テスト ケースが、製品のできる限り多くの部分をカバーしていることがとても重要になります。もう 1 つの優れたプラクティスとして、修正されたバグに対して単体テストを作成することもできます。これにより、バグを、自動化された方法で継続的に検証し、チェックすることができます。

常時結合の明らかな利点の 1 つは、透過性です。ビルド、およびテストの失敗は、次のビルドを待たずに、すぐに明らかになります。不具合のあるコードをチェックインした開発者は、まだ近くにいるかもしれません。すぐに変更を修正したり、元に戻したりすることができます。テスト ケースが十分に、慎重に作成されることにより、潜在的なバグの検出にかかる品質保証 (QA) 部門の負担は少なくなり、開発者もソフトウェアの品質に安心することができます。結果として、機能の開発、およびリファクタにかかる時間は長くなりますが、統合されてしまったエラーを検出するための時間は短くなります。

この記事では、この後、Visual Studio 2005 Team System、および Team Foundation Server を使用しての単体テスト、および常時結合を中心に説明します。確かに、これらのツールがなくても常時結合を導入することは可能です。CruiseControl.NET には、プロジェクトに常時結合を導入する別のツールのサンプルがあります。この記事では、Team Foundation Server によって、自動ビルドと、Visual Studio 2005 の新しい単体テスト機能とをどのようにシームレスに統合できるかを説明します。

ページのトップへ

3. Visual Studio 2005 Team System

Visual Studio 2005 Team System、およびそれが開発チームにもたらす新機能については、既に、たくさんの説明がされてきました。これらの機能に関する資料としては、Chris Menegay による記事「Visual Studio 2005 Team System による開発作業の一括管理」が優れています。

Team Foundation Server は、Visual Studio Team System の機能の多くが稼働するバックエンド サーバー コンポーネントです。その中でも目立つ機能が、新しいソース管理システムです。これは、Visual SourceSafe に代わるシステムであり、既存のソース コードを移行するための優れた変換ユーティリティも備えています。また、移行しない場合のために、Visual SourceSafe の新バージョンもリリースされています。

Team Foundation Server の機能は、ソース管理のみに限られません。バグ、タスク、およびプロジェクトのドキュメントなどの作業項目を追跡できます。これらの項目はバージョン管理されて保管されます。また、これらの項目は、ソース コードと同等に価値があり、必要であると認識されています。開発者に限らず、すべてのチーム メンバが、毎日完了させていく作業である項目は、Team Foundation Server に保管され、Visual Studio ユーザー インターフェイスによって提示されます。つまり、最もよく使用するツールの内でこのような情報を得ることができます。

Team Foundation Server は、Visual Studio クライアントとのやり取りを処理する Web サービスによって稼働します。作業項目の保管、およびバージョン間の逆差分として圧縮されたソースの保持には SQL Server? 2005 が使用されます。テスト結果、数的指標、およびコードの変更を示すプロジェクト関連のレポートは、SQL Server Analysis Services、および Reporting Services によって提供されます。プロジェクトの共同作業、およびドキュメント リポジトリのためのポータルは、Windows SharePoint Services によって提供されます。Visual Studio で作業を行わないチーム メンバは、このプロジェクト チーム サイトからプロジェクト情報、およびリソースにアクセスできます。

ソース コードは、スタンドアロン サーバーにインストール可能な Team Foundation Build Server を使用して一元的にコンパイルされます。コードが、ソース管理システムからチェック アウトされ、ビルドとテストが行われ、結果として出力されるビルドには、ネットワーク共有でアクセスできるようになります。複数のビルドの種類がサポートされているため、開発者、および構成管理者は、プロジェクトをどのようにビルドするかを制御できます。

Team Foundation Server の大部分は、Microsoft .NET Framework、および Web サービスを使用して作成されているため、イベントを取得し、Team Foundation オブジェクト モデルを使用することで、簡単に、タスクを自動化するようにカスタマイズを行うことができます。ここでは、ソース管理のチェックイン イベントに応答して常時結合を可能にするサンプルを説明します。

ページのトップへ

4. 単体テスト プロジェクト

例として、単純な .NET ライブラリを、エクストリーム プログラミングの原則に従って作成し、テストし、ビルドします。ここでは、.NET Framework 2.0 のジェネリックを使用して、基本的な計算関数を提供する数学コンポーネントを開発します。加算や減算などの計算関数のメソッドを、ジェネリック インターフェイスで定義します。これにより、Calculator ライブラリが、型に基づいて適切にメソッドを呼び出すことができるようにします。サンプルのライブラリの内容は、ここで説明する概念には重要ではありませんが、.NET ジェネリックの使用を理解するための参考となります。この記事のコードはすべて、C#、および Visual Basic の両方で使用可能であることに注意してください。

適切なエクストリーム プログラミングの手法に従って、まず、実装する各パブリック メソッドに対する単体テストを作成します。通常、単体テストを作成する前に、パブリック プロパティ、およびメソッドのスタブを作成しておきます。これは、Visual Studio に含まれる新しいクラス図の機能により、すばやく行うことができます (図 1 を参照)。

図 1 CalculatorLibrary のクラス図
図 1 CalculatorLibrary のクラス図

単体テストは、CalculatorLibrary クラスのパブリック メソッドに対して作成されます。Visual Studio Team System では、単体テストは、単体テスト プロジェクトとして新たにソリューションに追加されます。このプロジェクトには、Web ページ テスト、ロード テスト、コード単体テスト、さらに手動で実行するドキュメント テストを作成できます。ここでは、コード単体テスト クラスで計算のメソッドの正確性をテストします。図 2 は、リストに追加されたすべての項目の合計が 86 に等しいことを確認する単体テストの例です。例外が発生したり、値が 86 以外になった場合に、テストは失敗します。

図 2 Sum メソッドの単体テスト

'''<summary> テストの初期化 </summary>
<TestInitialize()> _
Public Sub Initialize()
    calculatorLibrary = New CalculatorLibrary(Of Integer)( _
        New Math.Integer.Calculator())
End Sub

''' <summary>
''' Int 型の Sum メソッドのテスト  (11+2+73=86)
''' </summary>
<TestMethod()> _
Public Sub TestIntSumMethod()
    Dim itemsToAdd As List(Of Integer) = New List(Of Integer)
    itemsToAdd.Add(11)
    itemsToAdd.Add(2)
    itemsToAdd.Add(73)
    Dim result As Integer = calculatorLibrary.Sum(itemsToAdd)
    Assert.AreEqual(86, result)
End Sub

Initialize メソッドには、テストをセットアップするために必要な処理を定義します。ここでは、Calculator オブジェクトを作成します。テストの初期化メソッドには、TestInitialize 属性を付ける必要があります。同様に、テスト メソッドには、TestMethod 属性を付けます。これらの属性は、メソッドが、Visual Studio のテスト フレームワークによって認識されるようにするために必要です。また後で製品をビルドするときにも必要となります。

図 3 ローカル テスト結果の確認
図 3 ローカル テスト結果の確認

単体テストが完成してから、Calculator ライブラリを実装します。これで、単体テストをローカルに実行する準備が整います。テスト マネージャでは、現在のソリューションに存在するすべてのテストを、選択して、実行することができます。図 3 に示す [テスト結果] ウィンドウには、すべてのテストが成功したことが示されています。これで次のステップに進む準備ができたことになるので、具体的に、Team Foundation Server に新しいチーム プロジェクトを作成し、ソリューションをそこに追加します。

ページのトップへ

5. チーム プロジェクトの作成

Team Foundation Server がネットワーク上でセットアップできていれば、Visual Studio からサーバーに接続するのは簡単です。[ツール] メニューで、[Connect to Team Foundation Server] を選択します。新しいサーバーを追加するオプションがあり、通常は、既定のポート 8080 で実行されるサーバーへの URL を使用します。ここでは、URL を TeamFoundation:8080 とします。

サーバーに接続するときに、新しいプロジェクトを作成できます。通常、プロジェクトの名前は、ソリューションの名前ではなく、より包括的な名前にします。ここでは、図 4 に示すように、プロジェクトの名前を MSDN Calculator とします。チーム プロジェクトは、通常、コードを作成する前の段階で、チームが構築するアプリケーションの定義フェーズを行っている間に作成します。チーム プロジェクトには、多数のソリューション、および Visual Studio プロジェクトが含まれます。しかし、より注目すべきなのは、このプロジェクトが単なるソース管理ではないという点です。チーム プロジェクトには、特定のロールを持つメンバが存在します。チーム プロジェクトは、特定のソフトウェア開発手法に従い、その手法に対応する各種の作業項目を保持します。また、チーム プロジェクトには、そのプロジェクトに関連する情報を伝達し、共同作業を行うためのポータルなどもあります。つまり、企業で、多数のアプリケーションが共有する共通クラスのセットを保持し、1 つのチーム プロジェクトでそれらの開発を管理する必要がある場合、そのチーム プロジェクトは、"エンタープライズ インフラストラクチャ" と呼ぶ方が適切とも言えます。ここでは、単純な例として MSDN Calculator を説明します。

図 4 新しいチーム プロジェクトの作成
図 4 新しいチーム プロジェクトの作成

次のステップでは、プロジェクトの詳細を定義します。まず、使用する開発手法に合ったプロセス テンプレートを定義します。Beta 3 では、選択肢として、Microsoft Solutions Framework (MSF) for Agile Software Development、および MSF for CMMI Process Improvement があります。ここではエクストリーム プログラミングの手法を使用しているので、アジャイル開発のテンプレートを選択します。ただし、このテンプレートはカスタマイズでき、また新規のテンプレートを作成することもできることに注意してください。このテンプレートによって、プロジェクトの作業項目、レポート、およびセキュリティ設定が決定されるので、テンプレートは重要な意味を持ちます。

次のステップは、プロジェクトのソース管理のセットアップです。これを行うためのインターフェイスは、Visual SourceSafe とあまり違いがありません。Visual SourceSafe の環境から移行するユーザーは、直感的に使用できます。ここでのプロジェクトでは、空のソース管理フォルダを作成する既定を受け入れます。フォルダの名前は、プロジェクトの名前から付けられます。

この設定が完了した後、行った設定がダイアログ ボックスで確認され、新しいプロジェクトが作成されます。新しいプロジェクトの作成には多くの処理が含まれるため、多少の時間がかかる場合があります。バックエンドで、SharePoint サイトが作成され、作業項目が生成され、レポートが定義されます。また、すべての他の設定がプロセス テンプレートに従って構成されます。この時点で、開発者、テスタ、および他の関係者のロールを定義し、プロジェクトにセキュリティを構成することができます。これで、項目をチェックインしたり、ビルドの設定を定義したりできるようになります。ここでは、Team Foundation Server を拡張して、常時結合をサポートするようにします。

ここまでで、.NET ライブラリを作成し、一連の単体テストを完成させ、新しいチーム プロジェクトを作成しました。次のステップは、単体テストが、Team Foundation Build Server でリモートに実行されるようにする準備です。

ページのトップへ

6. ビルド単体テストの作成

Visual Studio Team System では、テスト マネージャによって、自動的に .vsmdi という拡張子の付いたテスト メタデータ ファイルが作成されます。このファイルには、プロジェクトに対する単体テストの構成が含まれます。これにより、単体テストを、リモート ビルドで実行することができます。

ここでは、テスト マネージャ内の左側のペインを右クリックし、[新しいテスト リスト] を選択して、テストのリストを 2 つ作成します。1 つのリストには、CalculatorLibrary に Int を渡す単体テストを含めます。もう 1 つのリストには、Double を渡すテストを含めます (図 5 を参照)。手動テストは含めていないことに注意してください。これは、ビルドが、バックグラウンドで、人が介入することなく行われるためです。このデータは、.vsmdi ファイルに保管され、このファイルが、ソース管理にチェック インされます。

図 5 テスト マネージャでのプロジェクトのテスト構成
図 5 テスト マネージャでのプロジェクトのテスト構成

Team Foundation Server には、ソース管理へのチェックイン ポリシーを定義する機能がありますが、このプロジェクトでは定義を構成しないことにします。チェックイン ポリシーは、チーム内の開発者全体に統一性を徹底させるための優れた機能です。

図 6 プロジェクトの内容
図 6 プロジェクトの内容

この時点で、ソリューション、およびプロジェクトの設定は、図 6 に示すように構成されています。これは、メイン プロジェクトが Calculator ライブラリ、および単体テスト プロジェクトを含むことを示しています。テスト メタデータ ファイルも、ソース管理に連結された、ソリューションの項目として表示されています。

ページのトップへ

7. ビルドの定義

ここまでで、このプロジェクトのビルドの種類を定義する準備はできています。ここでは、数学ライブラリ、および単体テスト プロジェクトの両方をデバッグ ビルドとしてコンパイルし、定義した両方のテスト リストを実行するビルドを作成します。このビルドの名前は、Continuous Integration とします。この名前は、後でビルドをカスタマイズするときに使用されます。ビルド、あるいは何らかの単体テストが失敗したした場合には、開発者にその問題を修正するようにさまざまな方法で通知することができます。

チーム エクスプローラ ウィンドウの [Team Builds] オプションで、新しい種類のビルドを作成できます。ウィザードで、ビルドの種類の名前を指定し、コンパイルするプロジェクトを選択し、ビルド マシン指定します。ここで使用する構成では、ビルド サービスを Team Foundation Server にインストールし、そこで実行します。しかし、ビルドは、スタンドアロン サーバーで行うのが通常のシナリオです。ウィザードの最後のページで、ビルドが、プロジェクトをコンパイルした後に実行する単体テストを選択できます。ここでは、定義した単体テストの両方を選択します (図 7 を参照)。

図 7 ビルドの後に実行するテストの選択
図 7 ビルドの後に実行するテストの選択

Continuous Integration ビルドが定義できたら、Visual Studio チーム エクスプローラのユーザー インターフェイスからビルドを実行してみることが、そのビルドをテストするための最善の方法です。Continuous Integration ビルドは、チーム エクスプローラの [Team Build] フォルダの下に表示されます。単純に右クリックするだけで、チーム プロジェクトをビルドするオプションが表示されます。ビルドの状態は、Visual Studio 内にレポートされます。

ページのトップへ

8. Team Foundation Server の拡張

Team Foundation Server は、拡張性を考慮して構築されています。まず、イベント、特にソース管理イベントを取得する機能からこの特徴がよくわかります。Team Foundation Sever インストールには、このようなイベントを取得するために使用できる BisSubscribe.exe と呼ばれるコマンド行ユーティリティが含まれています。サブスクリプションをセットアップする前に、イベントを取得する Web サービスを作成します。Beta 3 では、BisSubscribe ユーティリティは、C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\TF Setup フォルダにあります。

BisSubscribe.exe では、取得するイベントの種類を定義できます。また、イベントを取得するために使用する Web サービス メソッドの正確なシグニチャ、および属性を定義します。Notify Web メソッドに対して生成されたプロキシを、次のように変更して機能するようにします。

<SoapDocumentMethod(Action:="https://schemas.microsoft.com/
TeamFoundation/2005/06/Services/Notification/02/Notify", _     
RequestNamespace:="https://schemas.microsoft.com/TeamFoundation/2005/06/
Services/Notification/02"), WebMethod()> _
Public Sub Notify(ByVal eventXml As String)
    ' イベントの機能を実装します。
    ThreadPool.QueueUserWorkItem(AddressOf BuildProject, eventXml)
End Sub

サブスクリプションを作成するには、次のコマンドを実行します。

BisSubscribe /eventType CheckinEvent /userId PICCOLO\TFSSetup /address 
TeamFoundation:8080/Continuous/Build.asmx /deliveryType Soap /domain 
TeamFoundation

address パラメータは、注意する必要があります。これは、Notify Web メソッドを含む Web サービスの場所です。最も簡単な場所としては、Team Foundation Server Web サービスを含む Web サイトの下に追加の仮想ルートを作成します (これは、Team Foundation Server アプリケーション プールを実行するアカウントには、ソースを読み取り、ビルドを開始する許可が既に付与されているためです。別の Web サービスをセットアップする場合は、ビルド中に必要な処理すべてを行うことのできる資格情報で実行するようにする必要があります)。これらの Web サービスの物理的な場所は、C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Web Services フォルダです。コマンド行のオプションからわかるように、ここでは、これらの要求をサービスするために Continuous という仮想ルートを追加しました。

Notify Web メソッドは、eventXml パラメータで XML ドキュメントを受け取ります。このドキュメントには、特定のイベントのメタデータがすべて含まれます。図 8 に、チェックイン イベント XML を示します。ここでは、MathLibrary.cs に意図的なエラーを含めてチェック インします。

図 8 チェックイン イベント XML

<CheckinEvent xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Artifacts>
    <Artifact xsi:type="ClientArtifact" 
      ArtifactType="Changeset" ServerItem="">
      <Url>http://TeamFoundation:8080//VersionControl/Changeset.aspx?
           artifactMoniker=90&webView=true</Url> 
    </Artifact>
    <Artifact xsi:type="ClientArtifact" ArtifactType="VersionedItem" 
      Item="MathLibrary.cs" 
      Folder="$/MSDN Calculator/Msdn.MathLibrary/Msdn.MathLibrary"
      TeamProject="MSDN Calculator" ItemRevision="111" ChangeType="edit"    
      ServerItem="$/MSDN Calculator/Msdn.MathLibrary/
                  Msdn.MathLibrary/MathLibrary.cs">
    </Artifact>
  </Artifacts>
  <Title>MSDN Calculator Check-in 111: Added intentional error</Title> 
  <ContentTitle>Check-in 111: Added intentional error</ContentTitle> 
  <Owner>PICCOLO\\bwaldron</Owner> 
  <Committer>PICCOLO\\bwaldron</Committer> 
  <Number>90</Number> 
  <CreationDate>10/15/2005 6:06:01 PM</CreationDate> 
  <Comment>Added intentional error</Comment> 
  <TimeZone>Pacific Daylight Time</TimeZone> 
  <TimeZoneOffset>-07:00:00</TimeZoneOffset> 
  <TeamProject>MSDN Calculator</TeamProject> 
  <PolicyOverrideComment /> 
</CheckinEvent>

Notify Web メソッドから、プロジェクトをビルドし、結果を開発チームにレポートする別のメソッドを呼び出します。図 9 に示すように、イベント XML から必要な情報を抽出します。ビルドの作成には、2 つのステップがあります。最初に、ビルドを開始するビルド コントローラに渡されるパラメータを作成する必要があります。この例では、最少のパラメータを示しています。ビルド コントローラは、Team Foundation Server の名前、プロジェクトの名前、ビルド サーバーの名前、およびビルド マシン上でコンパイルに使用するディレクトリを必要とします。事前に定義したビルドの種類も指定する必要があります。ここでは、前にチーム プロジェクトで定義したビルドの種類 Continuous Integration を使用します。

図 9 常時結合ビルドの開始

Private Sub BuildProject(ByVal state As Object)
    Dim eventXml As String = CType(state, String)

    ' イベント XML からの情報を解析します。
    Dim xmlDocument As XmlDocument = New XmlDocument()
    xmlDocument.LoadXml(eventXml)
    Dim teamProject As String = _
        xmlDocument.DocumentElement("TeamProject").InnerText
    Dim requestor As String = _
        xmlDocument.DocumentElement("Committer").InnerText
        Dim changeTitle As String = _
            xmlDocument.DocumentElement("ContentTitle").InnerText
        Dim offset As Integer = requestor.IndexOf("\"c)

        If offset > -1 Then
            requestor = requestor.Substring(offset + 1)
        End If

        ' StartBuild メソッドのビルド パラメータを作成します。
        Dim buildParameters As _
            Microsoft.TeamFoundation.Build.Proxy.BuildParameters = _
            New Microsoft.TeamFoundation.Build.Proxy.BuildParameters()
        buildParameters.TeamFoundationServer = FoundationServer
        buildParameters.TeamProject = teamProject
        buildParameters.BuildDirectory = BuildDirectoryPath
        buildParameters.BuildMachine = BuildServer
        buildParameters.BuildType = BuildType

        Dim status As BuildConstants.BuildStatusIconID = _
            BuildConstants.BuildStatusIconID.Default
        Try
            ' ビルド コントローラを作成し、ビルド、および記録を開始します。
            Dim buildController As BuildController = _
             BuildProxyUtilities.GetBuildControllerProxy(FoundationServer)
            Dim uri As String = 
                buildController.StartBuild(buildParameters)

            Dim buildData As _
                Microsoft.TeamFoundation.Build.Proxy.BuildData = Nothing
            Dim buildStore As BuildStore = _
                BuildProxyUtilities.GetBuildStoreProxy(FoundationServer)

            ' ビルドが完了するまで待機します。
            While status = BuildConstants.BuildStatusIconID.Default
                '1 秒待機して状態をチェックします。
                Thread.Sleep(1000)
                buildData = buildStore.GetBuildDetails(uri)
                status = CType(buildData.BuildStatusId, _ 
                    BuildConstants.BuildStatusIconID)
            End While

            If status = BuildConstants.BuildStatusIconID.BuildFailed Then
                ' チェック インした開発者の作業項目を作成します。
                AssignWorkItem(requestor, changeTitle, buildData)
            End If
            NotifyGroup(requestor, buildData)
        Catch soapEx As SoapException
            ' TODO: ビルド管理者に電子メールを送信します。
        End Try
    End Sub

ビルド パラメータを定義した後、Build Controller へのプロキシを取得します。これは、StartBuild メソッドを、定義したパラメータで呼び出す Web サービス プロキシです。StartBuild メソッドから、一意な統一リソース識別子 (URI) が戻され、これにより、ビルドの状態をチェックすることができます。ビルドを開始した後、別のプロキシを作成して、Build Store に接続します。このオブジェクトで、ビルドの状態、およびその詳細をチェックします。while ループを使用して Build Store に定期的に接続し、StartBuild メソッドからの URI を渡し、ビルドが完了したかどうかを判断します。

ページのトップへ

9. 作業項目の割り当て

ビルドが完了したら、ビルドの状態をチェックします。ビルドが失敗した場合には、AssignWorkItem メソッドを呼び出して、問題のあるコードをチェック インした開発者にこのケースを割り当てます。これを行うために、別の Web サービス プロキシ、Work Item Store を取得します。これにより、図 10 に示すようなコードで、新しい作業項目を作成し、保管できます。

図 10 新しい作業項目の割り当て

Private Sub AssignWorkItem(ByVal requestor As String, _
    ByVal changeTitle As String, ByVal buildData As _
    Microsoft.TeamFoundation.Build.Proxy.BuildData)
        
    Dim server As TeamFoundationServer = _
        TeamFoundationServerFactory.GetServer(FoundationServer)
    Dim store As WorkItemStore = _ 
        CType(server.GetService(GetType(WorkItemStore)), WorkItemStore)

    Dim workItemTypes As WorkItemTypeCollection = _ 
        store.Projects(buildData.TeamProject).WorkItemTypes
        
    ' 作業項目をバグとして入力します。
    Dim workItemType As WorkItemType = workItemTypes("bug")
    Dim workItem As WorkItem = New WorkItem(workItemType)

    workItem.Title = String.Format("Build {0} broken because " & _
        "check-in changes.  Investigate and correct: {1} ", _
        buildData.BuildNumber, changeTitle)
    workItem.Fields("System.AssignedTo").Value = requestor
    workItem.Fields("Microsoft.VSTS.Common.Priority").Value = 1
    workItem.Save()
End Sub

作業項目は、失敗となったビルドの開発者の [My Work Items] リストにタスクとして表示されます。ここでは、図 11 に示すように、意図的な失敗に基づいて作業項目が割り当てられています。このタスクは、開発者がエラーを修正するために必要とする詳細を提供し、さらに、この問題が完了となるまで追跡を行います。これらの作業項目からは、1 回のイテレーション中でビルドが何回失敗したか、エラーの修正にどれくらいの時間がかかったかなど、多くの指標が作り出されます。これらの情報すべてによって、開発作業の透過性が向上します。

図 11 自動的に割り当てられた作業項目
図 11 自動的に割り当てられた作業項目

作業項目を割り当てる以外に、ビルドの状態を通知する電子メールを開発チームに送信することもできます。電子メールは、ビルドが成功した場合にも送信できます。インスタント メッセージを送信したり、別の通知メカニズムを使用したりする機能を統合できることも、優れた拡張性ポイントの 1 つです。ビルドが失敗したときの電子メールの例を、図 12 に示します。

図 12 開発チームへの電子メールの自動送信
図 12 開発チームへの電子メールの自動送信

電子メールでは、新しくビルドされたプロジェクト、およびビルドのログへのリンクを提供します。ビルドのログには、ビルドの失敗、あるいはテスト ケースの失敗の原因を判断するために必要な情報が含まれています。このワークフローは全体が自動化されており、誰かが状態をチェックしたり、作業項目を手動で割り当てたりする必要はありません。これにより、開発チームは、最も重要な項目、つまり品質の高いソフトウェアを構築することに専念できるようになります。

ページのトップへ

10. まとめ

Visual Studio 2005 Team System、および Team Foundation Server には、アジャイル開発手法をサポートする多数の機能があります。この製品には単体テスト、および作業項目が組み込まれているため、Visual Studio では、これまでになく簡単に TDD の手法を採用できます。ここで説明したように、Team Foundation Server は、イベントを取得し、サーバーのインフラストラクチャに接続するだけで、簡単に、常時結合などのプラクティスをサポートするように拡張できます。

ページのトップへ

アジャイル開発の関連資料

アジャイル開発

エクストリーム プログラミング

適応型ソフトウェア開発

ダイナミック システム開発手法

スクラム

Microsoft Solutions Framework

ページのトップへ

Ben Waldron は、.NET に関するトレーニング、およびソリューションを提供する Piccolo Technology の創設者です。また、彼は Learning.com のリード アーキテクトでもあり、そこで技術教育ソリューションを開発しています。彼は、オレゴン州のポートランドを拠点としています。連絡先は、bwaldron@PiccoloTechnology.com です。

この記事は、MSDN マガジン - 2006 年 3 月からの翻訳です。

QJ: 060305

ページのトップへ