VS2005 TFS以前の常時結合と問題点

VS2005 TFS以前の常時結合と問題点

常時結合を行うためには、まずはソースコードをビルドし自動テストを行う仕組みが必要です。

VS2005 TFS以前にも、ビルドツールとして「NAnt」、自動テストツールとして「NUnit」を使うことで実現することができました。さらに、常時結合を行うツールとして「CruiseControl.NET」や「Draco.NET」を選択してきました。

ただし悪いことにそれらのツール類の保守は、一部のプログラマが有志で行うことがほとんどでした。この場合、その人がプロジェクトから抜けると誰も保守できなくなることが考えられます。このためNAntの使用方法を教育したり、ビルドファイルを保守するためのドキュメントを整備したりする必要があり、それらの工数は馬鹿になりませんでした。

さらに、NAntのビルドファイル（ビルドの設定ファイル）は、Visual Studioのプロジェクトファイルと互換性がなく、開発はデバッガやインテリセンスを利用するためにVisual Studioを使い、ビルドはNAntから行うという二重管理をすることがありました。この場合、保守性が非常に悪くなります（アセンブリの参照設定を行う際には、Visual Studioで参照設定したあとに、NAntのビルドファイルにも同様の修正を行う必要があります）。

またビルドツールやテストツール、常時結合のためのツール類はすべて別々のオープンソースのプロジェクトであり、すべてを利用して常時結合ができるシステムを構築するにはそれなりにノウハウが必要でした。

ゆえにこれまでの開発プロジェクトでは、費用対効果が小さすぎるため常時結合しようと考えるプロジェクトが少ないのではないかと感じています。

 

VS2005 TFSの自動ビルドによる常時結合

VS2005 TFSでは、自動ビルド機能を使うことで常時結合がスムーズに取り入れられると考えます。そして常時結合を行うためのツールは、表1のように変化していくのではないかと考えます。
 

その理由には、3つあると考えます。

 

ビルド機能、単体テスト機能、自動ビルド機能が1つのプロダクトセットによって提供されており、導入や管理性がしやすい

これまでフリーのツールを組み合わせながら常時結合を行うためのシステムを構築してきましたが、工数がそれなりにかかり、それに見合うだけのメリットを感じることができないプロジェクトが多かったのではないかと考えます。

しかしVS2005 TFSという1つのプロダクトセットによって、システムの構築を統合的に扱えることにより、導入や管理のコストの障壁はなくなるでしょう。

 

自動ビルドの枠組みの中で、品質面に関するチェックを行うことができる

単体テスト、コードカバレッジ、静的コード分析を自動で行うことができるため、常に品質面でのチェックを入れることができます。

 

ビルドの失敗を放置しない

面白いことに、VS2005 TFSではビルドに失敗すると自動的にバグ票が切られます。そして自動的に作業項目が新規作成されます。これにより、誰もがビルドの失敗を見て見ぬ振りをすることができなくなります。作業項目と連携されているのも、1つのプロダクトセットに統合されているがゆえのなせるわざです。
 

図1：開かれた作業項目
（画像をクリックすると別ウィンドウに拡大図を表示します）