3.2 VSTS / TFSの導入手順について
VSTS（TFS）を導入しようとする場合、開発プロセス全体を総取替えするような導入をすることは非常に危険である。確かにVSTS（TFS）は開発プロセス全体をカバーする製品ではあるが、例えばMSFのプロセステンプレートを全面的に採用しようとすると、その開発方法論なども理解する必要があり、導入のハードルが極端に高くなってしまう。一般的に、チームモデルや上流工程（要件定義）のやり方を一気に変更することはリスクが高い。このため、なるべく影響範囲の小さなところから徐々に入れていく方が現実的と言えるだろう。
3.2.1 導入範囲のポイント
先に解説した通り、もともとVSTS（TFS）はマイクロソフトのバグ追跡システムProduct Studioを原型として作られたシステムである。このことからもわかるように、TFSは特に下流工程において強みを発揮しやすい製品である。このため、図 3-4のように実装フェーズ以降でVSTS（TFS）を適用し、ソースコードやビルド、テスト結果やバグ追跡作業などを効率化すると、従来のやり方を大きく変えずにTFSを導入し、作業効率を改善していくことができる。
 |
| 図 3-4 段階的なVSTS（TFS）の導入シナリオ |
実際にTFSを導入する場合には、以下の手順でTFSの機能の利用を進めていくとよい*13。
- TFSソースコード管理システムを利用して、ソースコード管理を行う。
- TFS自動ビルドシステムを利用して、ビルドを自動化する。
- Visual Studio 2005のテスト機能を利用してテストを実施し、テスト結果をビルドに紐付けて管理する。
- TFSワークアイテムトラッキング機能を利用して、バグを管理する。
- TFSデータウェアハウス機能とレポーティング機能を利用して、溜め込んだデータを分析し、品質評価を行う*14。
|
*13 ここに記述したTFSの導入順序は実は極めて重要である。詳細な解説は第5章にて行うが、テスト結果のアップロード機能や分析機能、あるいはバグ追跡データベースシステムは、TFSの自動ビルドシステムに依存している。このため、TFSを利用してビルド作業を自動化していないと、TFSの各種機能の活用が限定的なものになってしまう。 |
|
*14 昨今、オフショア開発などへの要求の高まりから、TFSの品質評価機能だけを切り出してすぐに利用したいというニーズをよく耳にするが、これは不可能な話である。TFSの品質評価機能は、ソースコードやビルド、テスト結果やバグに関する情報をTFSサーバー上に溜め込んだ上で、これを分析することによって初めて実現されるものである。つまり、ソースコード管理、ビルド、テスト結果のアップロード、バグの管理までをTFS上で実践して初めて実現できるものであり、これらのタスクを飛ばして品質評価機能だけを行うことは原理的に不可能である。 |
3.2.2 論理作業フローと物理開発環境の違い
またTFSを利用した開発環境を作る際には、必ず論理作業フロー図を先に書き起こすようにしていただきたい。
開発環境の設計を行う際に、後に示す図 3-6のような物理構成図（サーバー構成やネットワーク構成、インストールするソフトウェアの一覧を書き出した図）を先に描く人が多いが、これは誤りである。物理構成図を先に書いてしまうと、チーム内やチーム間での「作業の流れ」が分からなくなってしまう。
このため、まず論理的な作業フローとして、各作業者の役割分担とやり取りされるリソースがどのようなものなのかがわかるようなイラストを描き、その次に物理環境を設計する、という手順で考えるのが望ましい。具体的な設計例を図 3-5と図 3-6に示す（本書の内容を超えるため、ここでは図を示すに留めることとする）。両者の図が全くといっていいほど異なることが見て取れるだろう。
 |
| 図 3-5 VSTS / TFSによる論理作業フロー図 |
 |
| 図 3-6 VSTS / TFSによる物理開発環境図 |
この2つの図が大きく異なるのは、TFSが開発環境におけるセントラルレポジトリサーバー（＝あらゆるデータを溜め込むサーバー）として機能するためである。作業項目（ワークアイテム）とソースコードやビルドは密接に紐づいており、また最終的に品質評価を行う際にはソースコードやビルド、テスト結果、バグなどに関するデータを1つにまとめて多側面的に分析・評価する必要がある。このような目的のためには、開発に関するすべての情報を一元的に管理したほうが有利である。
そのため、物理開発環境は、図 3-6に示すような構成（TFSを中央に配置するような環境構成）となるのである。
以上、VSTSやTFSの導入手順について解説したが、VSTSのさらに詳しい情報については各種の関連書籍での学習を進めていただきたい*15。本書ではTFSに関するこれ以上の深入りを避けるが、TFSを利用するとさらなるメリットが得られることは理解しておくとよいだろう。
3.3 VSTSとTFSによるソフトウェアテストの全体像 ― まとめ
本章の解説をまとめると、以下のようになる。
-
開発チームは、Visual Studio 2005 Team Edition for Software Developersを使う。
- アプリケーションの生のソースコードを直接触ることができるチーム。
- 主に、単体機能テストツールや静的コード分析などを利用する。
-
テストチームは、Visual Studio 2005 Team Edition for Software Testersを使う。
- 完成したバイナリファイルを対象として検証作業を行うチーム。
- 主に、手動テストやWebテストツールなどを利用する。
-
さらにチーム開発を円滑に進めるため、Team Foundation Serverを使う。
- TFSがセントラルレポジトリサーバーとして機能する。
- ソースコード、ビルド、テスト結果、バグ情報などを一元的に管理できる。
- さらに、それらのデータを用いて品質評価分析を行っていくことができるようになる。
Insider.NET 記事ランキング
本日
月間
