Visual Studio 2005の変更管理の有効性

はじめに

ソースコードとドキュメントは互いに依存しています。ゆえに、すべてのソースコードとドキュメントはプロジェクトメンバー間で共有されていなければなりませんし、内容の変更も管理し、さらに関連まで持たせておかなければなりません。そうしておかないと、ドキュメントとソースコードの内容が一致せず、あとで保守する人（注）が苦労してしまいます。
 

また、ビジネスの変化が早い昨今、システムの短期開発が求められています。それにともない、開発の現場ではフェーズ分割された並行開発が多くなっています。その並行開発において、ソースコードはフェーズにまたがってきちんと変更履歴を管理しておかないといけません。そうしておかないと、何度も同じバグを発生させてしまいます。

というわけで本連載「チーム開発ここまできた、個人からチームの生産性向上へ」の第2回の今回は、チーム開発の肝とでもいうべきVisual Studio 2005 Team Foundation Server（以下、VS2005 TFS）の変更管理機能の管理コスト、品質向上、時間の短縮の面での有効性について考察していきます。

 

管理コストの削減

Windows XPなどのアジャイル開発プロセスにおいて、ソースコードの変更管理はそれほど厳密に行う必要はないかもしれません。というのも、最終的にできあがったソースコードが、テストをパスできていればそれでよしとしているからです。ですが、ほとんどのプロジェクトでは何らかの変更管理をしているはずです。

例えば、テストチームで発見されたバグが修正依頼書としてあがってくることがあります。また、税率の計算ロジックの変更や画面の入力項目の追加などの突然の変更要求が変更依頼書としてあがってくることもあります。

そしてプログラマは、依頼書を元にプログラムを修正してテストします。その後、報告書に変更したソースコードの一覧を記入したり、その変更内容や影響度を記述したりします。最後にコードレビューを経て、報告書はWord文書で共有フォルダに、ソースコードはソースコード管理システムにチェックインします。一連の作業は、標準化されてはいますが、慣れるとついついサボりがちになったり、提出するドキュメントが多すぎて記述ミスが多くなったりします。

またテストチームや、クライアントへ出荷するモジュールの管理も面倒でした。Visual SourceSafe（以下、VSS）では、分岐という仕組みを利用すればできますが、あまり知られていないからか使われていません。このため、リポジトリを分岐せずに開発を行ったがために、発生した不具合がどのフェーズのソースコードに潜んでいた問題なのかを切り分けるのが難しくなることがあります。

これらの問題をVS2005 TFSでは、変更セットとブランチ、マージによって解決できます。