matsukawar’s blog

個人的な技術ブログです。SAPネタを充実したい。Twitter : https://twitter.com/matsukawar

VSSからTFSに移行するメリット

VSSからTFSに移行したときのメリットをメモ。
勢いで書いたので、思いついたら追記してきます。

はじめに
VSSからTFSに移行すればいいことは分かってるし、MSDNも購入済み。
でも、開発現場や導入のために他の人たちを説得しなければならない、というケースもあると思います。この記事が、TFSを導入しようとしている人にとって参考になればと思います。

  • (1)より安全なレポジトリ

VSSは共有ファイルの方式でデータを管理しているので、使っているうちに必ずといっていいほど、ファイルが壊れたり、正しい整合性が保てなくなります。ソースシュレッダーといわれるゆえんです。

VSSを使い続けることは、会社の資産をシュレッダにかけるようなものといえます。従って、会社の資産を守る上でも、VSSからTFSへの移行(TFSでなくてもSVNでもなんでもいいですが)は推進していく必要がある、というのが基本姿勢です。

TFSはSQL Server(データベース)を使っているので、同時にチェックインなどのレポジトリの操作が発生し、競合したとしても、壊れることはそうありません。
一方、VSSは、独特のアルゴリズムによってデータを断片化してファイルサーバに保持する仕組みで、ひとたび競合が発生すると、ファイルの整合性が破壊されます。

「壊れないよ〜!」という人が稀にいますが、VSS付属のアナライズツールを走らせると、たいてい整合性が壊れています。

また、データの管理、復元やバックアップもSQL Serverの仕組みがそのまま使えますので、管理者サイドの手間も減ります。

メリット

  • レポジトリの整合性が取れなくなってくると、履歴の参照やちょっとした操作で、VSSが異常終了することがありますがその手間がほとんど無くなります。
  • VSSが異常終了すると、VSSを再起動する手間がかかっていましたが、異常終了がほとんど無くなったことからこの手間が省けます。
  • バックアップがしやすくなります(SQL Serverの仕組みをそのままつかえる)。

※作業の途中だったのにVSSが落ちた場合最悪です。最初から整合性を確認しないといけません。そのために、ファイル比較をしますが、この操作が原因でまた落ちる可能性が大です。このような負の連鎖が発生すると最悪です。

検討項目

  • SQL Server(有償版)を使用する際には、ライセンス料が高価であるため検討に検討が必要となります。
  • VSSのデータが既に破壊されて、復元が出来ない状況の場合、TFSではどうしようも無いので、"どうにかして"データを復元する必要があります。VSSの分析ツールでどうにかなればいいですが・・・分析ツールを信頼して使っても大丈夫かどうかは分かりません。
  • (2)変更セット

VSSには変更セットという考え方がありません。ファイル単位で管理しています。
しかも、ファイルの差分ではなく、ファイルの複製で管理してます。これはVSSのレポジトリの容量が増える要因になっています。

近年は、HDDの価格が安いので、レポジトリの削減は導入理由にはならないかもしれませんが、ブランチ(分岐)を頻繁に作成すると、容量が劇的に増加してバックアップも大変になってきます。HDD容量は十分でも、バックアップにかかる時間的なコストがドンドン大きくなります。


一方、TFSでは、変更セットでデータを管理しています。変更セットはファイル単位ではなく、同時にチェックインしたファイル郡の"差分"として管理されています。
開発者が同時に、何をチェックインしたのか」が明確にわかります。

TFSの特徴のひとつはこの様に、情報の追跡可能性の向上といえます。

メリット

  • 今までは、VSSの検索機能を駆使して、誰が何をいつチェックインしたのか検索していたが、TFS上では、1つの変更履歴をダブルクリックするだけで、これらの情報を追跡できるので手間が減る。
  • ブランチを頻繁に作っても、レポジトリの容量は劇的に増えないので、バックアップなどサーバ側の運用の手間が減る。
  • (3)共有チェックアウト

VSSのときにも、「共有チェックアウト」という機能が確かにありましたが、現場を混乱に陥れる機能でもありました。

例えば、共有チェックアウトした項目がいくつか含まれている"保留中のチェックイン"を、チェックインしていったときに、途中でマージの問題が発生し、チェックインを中断せざる終えなくなったとします。

しかしこの場合、VSS上には途中までチェックインされてしまってるため、マージ作業を中断できません。マージに責任を負えなくなっても、中断できません。ここで、チーム全体がレポジトリを触れなくなります。この状態は、すなわちレポジトリを汚した状態です。


仕方ないので、途中までチェックインされたものをロールバックしようとしますが、これはかなり面倒な作業になります。ロールバックしてる間、他の開発者がレポジトリを操作するのを中断してもらう必要があります。チームの作業の効率が落ちます。

一方、TFSの変更セットは、「すべてコミット完了」でチェックイン完了となり、それ以外は、キャンセルされます。"途中"という中途半端な状態がありません。

メリット

  • 共有チェックアウトしたときに、マージが必ず発生しますが、変更セットをチェックインする際には、マージがすべて完了してコミットが完了となるまでチェックインされません。チェックインの途中でマージが発生した場合、作業を中断してマージに専念できるようになります。この間レポジトリを汚すことはありません。
  • Team Explorer標準搭載されている、"マージツール"が用意されているので、コードのマージがしやすい環境が整っています。もしも、マージの際にオリジナルのツールを使用したいという場合は設定を変えることで、別ツールも使えます。

ワークスペースという考え方もVSSには無い考え方です。ワークスペースはVSSの「フォルダの設定」と同等の設定を「マップ」と呼んだ上で、マップの集合体をワークスペースとして定義することが出来ます。

ここで重要なのは、変更セットはワークスペースごとに管理されている、ということです。複数の仕事を1つの机の上でやるのではなく、仕事ごとに、机を移動して作業をするという考え方です。ワークスペースを切り替えれば、まったく別の作業領域で開発を進めることが出来ます。

VSSの場合、異なる作業を同じ作業領域でやった場合、保留中のチェックインウィンドウ内に表示される項目はごちゃまぜの状態になります。何が、この作業の修正で、何が別の作業の修正なのか分かりません。

メリット

  • 同時並行開発が楽にできるようになります。
  • ワークスペースを切り替えれば、今までの作業を中断して、別の作業にすばやく移行できます。

検討項目

  • ワークスペースの考え方をチームメンバー全員がきちんと理解する必要があります。勉強会やWikiなどを駆使してフォローする必要があります。
  • (5)速度が早い

速度が速いです。

特に、最新バージョンの取得に関していうと、1.5倍くらいは早いと思われます。
私のチームでは膨大なソースコードをVSSから取得するために、30分くらいはかかっていましたが、いまでは、10〜15分に短縮できています。
この速さは、SQL Serverをバックグラウンドで使用している点が影響していると考えられます。(キャッシュされるから?)ちなみに、こんなに早くなるとは導入前は思っていませんでした。

  • (6)ブランチング機能

バージョン・ブランチング(分岐、マージ)がしやすい環境が提供されます。私のチームではSVNのバージョン管理方法を真似していますが、そのようなことが容易に実現できます。
VSSの場合、レポジトリを丸ごと複製して、バージョン分岐をしたり、ラベルを切って管理したりしていました。

VSSで、バージョンのマージをするとなると大変です。ファイルの差分を取って、1個ずつマージすることになります。もちろん、盆ミス、間違えが頻発する事が目に見えています。

TFSでは、常に分岐とマージを繰り返す仕組みが整っていますが、マージの作業のほとんどを機械的に実施してくれます。差分が無いファイルはマージするファイルから除外してくれますし、マージが必要な場合であってもたいていは機械的なマージで完了です。

レポジトリの容量について
私のチームでは、日々開発されたコードを、リリースのために毎月のようにバージョン分岐したり、マージしたりしています。ここで、一定期間にわたり、レポジトリの容量の増加量を監視した結果、およそ、1ヶ月に1GBほどの増加でした。
※コードのレポジトリの使用量のみ。タスク, テスト管理を除く。

この調子で行けば、HDD容量が100GBあれば、5年はもちそうです。しかし、サーバのHDDの容量はTBが主流ですので、あまり気にすることはなさそうです。TFSを導入した際には、このように、データベースの容量の測定を行って、後々の分析や計画に生かしていくといいかもしれません。