Team Foundation サービス

[アーティクル]
06/17/2015

Team Foundation サービスプレビューでビルド自動化を実装する

今回は、Team Foundation サービスプレビュー (以下、TFS プレビュー) でビルドの自動化を実装する方法について説明します。Visual Studio ALM Rangers では、3 月から TFS プレビューを使用して、ビルド全体をクラウドで行っています。TFS プレビューでは、ゲートチェックインやカスタムのビルド定義など、チームビルドのすべての機能がサポートされていますが、今回重点を置くのは、TFS プレビューの基本的なビルド機能ではありません。今回は、開発チームが Windows Azure で利用できるビルドコンピューターの構成をさらにきめ細かく制御する必要があるシナリオを想定し、オンプレミスでビルドの自動化をセットアップする方法を取り上げます。

TFS プレビューでビルドを実行する方法の詳細については、Aaron Bjork の「Visual Studio ALM + Team Foundation Server Blog」(Visual Studio ALM と Team Foundation Server に関するブログ、bit.ly/H9epDn、英語) を参照してください。

毎回のことですが、Rangers は、不足している機能に対処し、導入を妨げるものを取り除き、実世界での経験に基づいたベストプラクティスとガイダンスを提供しながら、Visual Studio 製品グループ、Microsoft サービス、および Microsoft Most Valuable Professional (MVP) コミュニティの間の連携を推し進める専門家グループです。

TFS プレビューを Team Foundation ビルドサービスに接続する

ソフトウェアプロジェクトのビルドを自動化するには、Team Foundation ビルドサービスを使用して、オンプレミスまたはホスト型シナリオで実行されるビルドコンピューターをセットアップします。ビルドコンピューターをセットアップしたら、コンパイル対象のコードプロジェクトに関する指示やその他多数のオプションの構成方法に関する指示を含むビルド定義を Visual Studio で作成する必要があります。開発者は、まず Team Foundation ビルドサービスの配置シナリオを選択してから、ビルドコンピューターを適切にセットアップする必要があります。

インストールの準備: TFS プレビューに接続するコンピューターに Team Foundation ビルドサービスをインストールするには、次の手順を実行しておく必要があります。

Team Foundation Server 2012 で提供されている Team Foundation ビルドサービスを使用するようにします。Team Foundation Server 2010 のビルドエージェントとビルドコントローラーには、Windows Azure 上の Team Foundation サービスプレビューとの互換性がありません。Team Foundation Server 2012 に付属しているビルドサーバーソフトウェアを使用する必要があります。
TFS プレビューをサブスクライブします。
TFS プレビューのプロジェクトコレクションを指定する URL を特定します。
お使いのユーザー資格情報を構成して、この資格情報に "コレクションレベル情報の編集" アクセス許可を付与します。このアクセス許可は、プロジェクトコレクションビルド管理者グループの既定のアクセス許可に含まれています。
ファイアウォールを構成して、ホストされている仮想マシン (VM) のファイアウォールで TCP ポート 9191 経由の受信接続を許可します。これにより、TFS プレビューがビルドサービスと通信できるようになります。ビルドコンピューターのセキュリティと整合性を確保するために、Windows ファイアウォールを常に有効にしてください。

インストール、構成、および実行: 物理ホストコンピューター上または TFS プレビューに関連付けられている VM 上に Team Foundation ビルドサービスを配置する手順は、オンプレミスの Team Foundation Server を配置する手順とほぼ同じです。この手順は、MSDN ライブラリの記事「方法: Team Foundation ビルドサービスをインストールする」(msdn.microsoft.com/ja-jp/library/ee259687.aspx) および ALM Rangers によるガイド「Team Foundation サービス向けにビルドをインストールする」(go.microsoft.com/fwlink/?LinkID=251576、英語) で説明しています。

最大の違いは、ビルドの格納場所のセキュリティを確保する方法です。物理ホストコンピューターや VM にビルドの格納共有フォルダーを作成することはできますが、その共有フォルダーを直接インターネットに公開しないでください。ビルドサーバーの攻撃対象領域を拡大することはお勧めしません。図 1 に示すように、IIS のセキュア FTP を使用してビルドの格納フォルダーを公開することが、ビルドをインターネット経由で安全に公開する最善策と言えます。

Secured Build Drop Access
図 1 セキュリティが確保されたビルドの格納場所へのアクセス

パフォーマンス、帯域幅、およびダウンロードの懸念事項の対処: ビルドの自動化では、一般に大量の I/O 操作が行われます。ほとんどのビルドではソリューションのソースコード全体がダウンロードされることを考えると、利用できる帯域幅とダウンロード容量の上限を考慮しておくことが重要です。1 回のビルドでダウンロードするファイル数を削減するため、Team Foundation Server プロキシのセットアップを検討します。このプロキシは、ソース管理のファイルのコピーをリモートの場所にキャッシュして、ネットワークスループットを向上します。プロキシによりコピーがオンプレミスにキャッシュされるため、ビルド処理中にファイルをダウンロードする負荷が回避されます。オンプレミスでコピーをキャッシュすれば、確実に帯域幅使用量も削減できます。これはインターネットサービスプロバイダーが設けているダウンロード容量の上限に効果があるだけでなく、ビルド処理全体のパフォーマンスも向上します。

オンプレミスのビルドサーバーを構成する

クラウドの TFS プレビューを利用するオンプレミスのビルドサーバーを配置するには、Web ホスティングの考え方や業界の慣行を流用します。ほとんどの企業 Web ホスティング環境では、境界ネットワーク (別名、非武装地帯 (DMZ) またはスクリーンサブネット) を使用して、セキュリティが確保されたネットワークや領域を作り出します。境界ネットワークは、インターネットに公開されるサーバーと企業ネットワークとを分離します。

境界ネットワークを実装する方法は 2 つあります。従来の実装方法では、物理的に異なる 2 つのファイアウォールを使用し、各ファイアウォールで、ネットワーク間で送受信されるトラフィックの流れを制限します (図 2 参照)。

図 2 2 つのファイアウォールで分離される境界ネットワーク

境界ネットワークの比較的新しい実装方法として、セキュリティが確保された仮想ローカルエリアネットワーク (VLAN) を使用し、1 つのファイアウォールですべてのネットワークトラフィックを制御する方法もあります (図 3 参照)。

A Perimeter Network with Virtual Local Area Networks
図 3 仮想ローカルエリアネットワークを使用する境界ネットワーク

TFS プレビューと Team Foundation ビルドサービスで通信するためのファイアウォール構成

メーカーによってファイアウォールの構成に多種多様なバリエーションがあるため、ここでは概念のレベルに限定して説明します。今回の説明の中でのファイアウォール構成で重要な点は、公開とアクセスルールの 2 つです。

公開とは、ファイアウォールの外部とのインターフェイスやワイドエリアネットワークで、TCP ポートとユーザーデータグラムプロトコル (UDP) ポートを開いて、Web アクセス、電子メール、仮想プライベートネットワークなどのサービスをインターネット経由で利用できるようにすることです。ビルドサーバーをセキュリティが確保された状態に保つには、次のようにファイアウォールの公開方法を定義する必要があります。

インターフェイス: 外部
ポート番号: 9191
TCP/UDP: TCP
範囲: すべてのネットワーク (インターネット)

範囲を "すべてのネットワーク (インターネット)" に設定していることに注意してください。公開の範囲を TFS プレビューの一連の IP に制限して、インターネット上の他のクライアントやホストがこのコンピューターにアクセスしないようにすることを考えます。トラフィック制限を追加すると、セキュリティに新たな層が加わります。TFS プレビューの最新 IP を取得するには、DNS ネームサーバーの参照を実行します。ただし、IP は随時変化する可能性があります。ファイアウォールによっては、ホストの完全修飾ドメイン名の逆引き参照を実行して、最新の IP を監視する機能があります。

アクセスルールとは、ファイアウォールの内部インターフェイスと外部インターフェイスの間のネットワークトラフィックに設ける制約です。ビルドサーバーをセキュリティが確保された状態に保つには、ファイアウォールのアクセスルールを定義する必要があります (図 4 参照)。

図 4 アクセスルールの定義

送信元

送信先

プロトコル

ポート

アプリケーション

内部ネットワーク

(ビルドサーバーの IP)

外部インターフェイス

(インターネット)

HTTPS

8080

TFS プレビューとのセキュリティ保護された通信

外部インターフェイス

(インターネット)

ビルドサーバー (IP)

HTTPS

9191

Team Foundation ビルドサービスのエンドポイント

侵入検知: あらゆる Web ホスティングインフラストラクチャと同様、Team Foundation ビルドサービスのサーバーをインターネットに公開する際は侵入検知の実装を検討する必要があります。

TFS プレビューと Team Foundation ビルドサービスとの通信の保護: ビルドサーバーが使用するサービスを構成することによって、TFS プレビューに接続されたオンプレミスのビルドサーバー配置のセキュリティを強化できます。配置のセキュリティを最大限に強化するために、SSL を使用する HTTPS を要求するよう構成することをお勧めします。

SSL を使用する HTTPS を要求するようサービスを構成するには、次の要件があります。

民間証明機関 (CA) が発行した SSL 証明書
登録済みのインターネットドメイン名
登録済みのドメイン名を使用してビルドサーバーの外部 IP (インターネットとインターフェイスを持つ IP) に解決される、DNS ホスト名レコードまたはエイリアス (CNAME) (民間の CA から SSL 証明書を取得するには、登録済みのドメイン名が必要)
ビルドサーバーでのローカル管理者特権
ファイアウォール上にあるビルドサーバーの外部 IP アドレスにマップされる内部 IP アドレス

このような要件を満たしたら、ファイアウォールで TCP ポート 9191 を開いてそのポートにビルドサーバーの内部 IP アドレスを転送し、Team Foundation ビルドサービスが SSL を使用するよう構成します。

Team Foundation Server 2010 ビルドサービス向けに SSL を構成する方法については、MSDN ライブラリのセクション「ビルドサーバーへの証明書のインストール」(msdn.microsoft.com/ja-jp/library/aa833872.aspx#InstallBuildCert) を参照してください。

認証の設定: ビルドサービス構成ウィザードを実行して Team Foundation ビルドサービスのインスタンスを TFS プレビューに追加するには、次の 2 つのユーザーアカウントが必要です。

TFS プレビューアカウントのプロジェクトコレクションにマップされる Windows Live ID (サブスクリプション)
ビルドサーバーのサービスアカウントとして使用するローカルユーザーアカウントまたはドメインユーザーアカウント

ビルドサービス構成ウィザードでは、初期構成の段階で Windows Live ID を使用して TFS プレビューにアクセスできるようにし、プロジェクトコレクションとビルドサーバーのマッピングを確立します。続いて、ドメインユーザーアカウントまたはローカルユーザーアカウントのサービスアカウント資格情報を指定します。ドメインユーザーアカウントをサービスアカウントとして使用するのがセキュリティに最も適したオプションです。ドメインユーザーアカウントは、簡単に別のサーバー上のフォルダー共有を使用できます。

ビルドの監視: Team Foundation Server 2010 Power Tools (2011 年 12 月) リリースに付属する Build Notifications パワーツールを使用すると、ビルドを監視できます。図 5 に、[Build Notifications Options] (ビルド通知オプション) ダイアログボックスを示します。Visual Studio 2012 で作業している場合は、Team Explorer 2010 SP1 と GDR の互換性に関する更新プログラムをインストールしてから、Team Foundation Server 2010 Power Tools をインストールする必要があります。同一コンピューターへの Visual Studio 2012 と Visual Studio 2010 のサイドバイサイドインストールがサポートされているため、バージョンの競合については心配することはありません。

Monitoring Build Status
図 5 ビルドの状態の監視

ホストビルドコントローラーによりチームビルド定義を構成する

TFS プレビューでは、アプリケーションのコンパイル、テスト、およびパッケージ化を実行できるビルドコンピューターのプールが提供されます。

ホストビルドコントローラーの構成: ホストビルドコントローラーを使用するのに必要な構成は、ビルド定義の [ビルドの既定値] タブでホストビルドコントローラーを指定することだけです (図 6 参照)。

Selecting a Hosted Build Controller
図 6 ホストビルドコントローラーの選択

制約の対処: TFS プレビューでは、ビルドコンピューターを完全には制御できません。つまり、プロジェクトに外部依存関係が存在する場合、その依存関係をチェックインするか、パブリックな NuGet フィードからダウンロードできるようにする必要があります。

Visual Studio 2012 と Visual Studio 2010 SP1 (GDR の互換性に関する更新プログラムが必要) の開発環境は TFS プレビューのビルドイメージにインストールされるため、これらのバージョンの Visual Studio で作成したプロジェクトだけがサポートされます。

Windows ストアアプリをビルドする場合は、ビルドサービスを Windows 8 にインストールする必要があります。Team Foundation ビルドを使用して Windows ストアアプリをビルドおよびテストする方法の詳細については、bit.ly/T3tFSt (英語) を参照してください。

単体テスト: TFS プレビューでは、ビルドの一環として単体テストをサポートしています。MSTest テストを使用した単体テストは、追加構成の必要なく機能します。NUnit や xUnit など、他の単体テストフレームワークを使用してテストを実行するには、対応するテストアダプターのアセンブリがソース管理にチェックインされていることを確認してから、ビルドコントローラーの [カスタムアセンブリへのバージョンコントロールパス] プロパティをこのアセンブリの場所に設定します。

複雑なビルドシナリオの特定: お使いの環境に最適なビルド構成の決定は、ビルドの複雑さによって異なります。自動配置を実行しない単純なビルドシナリオの場合は、TFS プレビューでホストされるビルドサービスで十分です。より複雑なビルド処理で、オンプレミスのビルド構成を使用します。複雑なビルド構成には、次の条件のうち少なくとも 1 つを満たすビルドテンプレートを含めることになります。

ワークフローに自動配置のアクティビティが含まれる。
Visual Studio 2010 SP1 よりも前のバージョンの Visual Studio で作成したソリューションが含まれる。
Visual Studio Lab Management を呼び出す。
オンプレミスのコンピューターと連携する。
Visual Studio のテストアダプターが提供されていないテストフレームワークを必要とする。

サードパーティ製アセンブリを必要とするソリューションは、そのアセンブリをバージョン管理にチェックインするか、ソリューションでアセンブリをパブリックな NuGet フィードからダウンロードできるようにすれば、TFS プレビューでビルドできます。

自動テストと Lab Management: 現時点では、TFS プレビューは Visual Studio Lab Management をサポートしていませんが、Visual Studio で数種類の自動テストを作成して実行できます。以下に、いくつか例を示します。

単体テスト
コード化された UI テスト
Web パフォーマンステスト
ロードテスト
汎用テスト

ビルドの完了後に、これらのテストを実行してビルドの品質を評価できます。このようなテストは、一般にビルド確認テスト (BVT) またはスモークテストと呼ばれます。通常、BVT は幅広い一連のテストで構成され、特定のビルドでアプリケーションの主要領域を確認するために使用します。BVT を構成するすべてのテストにビルドが合格すれば、そのビルドは成功と見なされます。

オンラインの MSDN ライブラリの記事「方法: アプリケーションのビルド後にスケジュールされているテストを構成および実行する」(bit.ly/P2EKB7、英語) では、BVT の作成と実行に必要なすべての手順について説明しています。

チームビルドでのコード化された UI テストの実行: コード化された UI テストを使用すると、BVT をさらに優れたものにできます。コード化された UI テストでは、テスト実行の一環としてアプリケーションを起動します。必ず、アプリケーションの起動に使用するビルドサービスのサービスアカウントを構成してください。このサービスアカウントは、そのコンピューターのアクティブユーザーのユーザーアカウントと同じものにする必要があります。サービスアカウントとユーザーアカウントが異なる場合、アプリケーションは起動しません。また、Team Foundation Server 管理コンソールまたは Team Foundation ビルド構成で、ビルドサービスホストのプロパティ [ビルドサービスを次の形式で実行します] を [対話型プロセス] に設定していることを確認することも必要です。

今後の展望

今後のコラムでは、アウトソーシングモデルの一環として遠隔地の開発組織のサービスを活用しようと考えているエンタープライズ規模の開発組織向けに、共同作業を実現するように TFS プレビューをセットアップおよび構成する方法について説明します。ALM Rangers の詳細については、bit.ly/HrYqAl (英語) を参照してください。

Mario Contreras は、トロントに拠点を置く Microsoft Consulting Services のシニアコンサルタントであり、ALM コーチでもあります。また、テクニカルカンファレンスで頻繁に講演を行っています。Microsoft Canada での在職期間中、Contreras は最も大規模な Team Foundation Server 実装のいくつかでリーダーを務めました。Contreras は、Visual Studio ALM Rangers チームのアクティブメンバーです。

Tim Omta は、フェニックスのシニアアプリケーション開発マネージャーです。彼はマイクロソフトで製品開発者とテスト開発者の両方として勤務経験があり、現在はマイクロソフトの開発者向けのプレミアサポートを通じてフィールドコンサルタントを務めています。Omta は、ALM Rangers のアクティブメンバーです。

Tim Star は、Intertech Inc の主任コンサルタントで、トレーニング、コンサルティング、Visual Studio ALM を担当しています。MCPD、MCTS、MCT、および Visual Studio ALM External Ranger の資格を持ち、MVP を 3 度受賞しています。彼はコードを記述したり、ALM ガイダンスを作成および提供したりしています。

この記事のレビューに協力してくれた技術スタッフの Jim Lamb、Mario Rodriguez、Willy-Peter Schaub、および Patricia Wagner に心より感謝いたします。