Share via

Visual SourceSafe から Team Foundation Server へのアップグレード

  • Article

TFS 2005/2008 から TFS 2010 のアップグレードは? と聞かれると、痛いです。
何故なら、書いてたマテリアルを開いたまま、マシンが死んでしまったので、10ページ程になったマテリアルはぶっ飛び…書き直す気力がないっす…書いたら、何くれる?? w

最近はもっぱら System Center な話ばかりになっています、ロバートです。
何故ならプレミア フィールド エンジニアとしての担当製品が Windows Platform 全般と System Center 系全般だからです。
そう…全般。全部。全て。System Center とつけば、僕が担当なんです (ひゃ～～～)
でも、楽しいですよ (笑)

でも、技術的なワークショップやトレーニングの講師として資格を沢山とっていっても、英語のマテリアルなので、日本では使いようがないと言う事実に腹が立つこともあったり。ちょうどその為、今はシンガポールに来てますが…
日本だけ、英語のマテリアルを受け入れない…日本だけ、全てのコンテンツをゼロから日本向けにだけ作らなきゃならない…それだけに、社内においてシステマティックに成果を認めてもらえない。 アメリカの会社ですからね…
言うだけ言ってみよう: 日本のエンジニアの皆さん、基礎レベルの英語を覚えましょう。学校で学んできたものじゃなく → 日本の学校で教える英語ほど、世の中で使えないものはありません。 ← よく、英語の教え方を変えないでここまできていると、本当に不思議に思いますよ…どうにかしよう、教育制度! (え?脱線しすぎですか?) 家系に文部大臣がいたせいですかね…なんか、教育については熱くなります…さておいて…

 

今日は SCOM 2007 R2 のディープ技術トレーニング中に現実逃避 (コラっ!) ← 書き始めはね
ずっと書こうと思っていた、Visual SourceSafe から Team Foundation Server への移行についてです。

 

VSS から TFS へのアップグレード: 検討すべき理由

Visual SourceSafe (VSS) が世に出てきた当時は、シンプルかつそれなりにフレキシブルな開発のバージョン管理システムで、多くの当時の開発者のニーズに応えることができていたかと思います。もっと言うなら、今でも充分な機能を持っていると言うお客様も少なからず…当時は、インターネットも普及してなく、内部ネットワークもさほど使われておらず、アプリケーションがデータを共有するなどもっての他だった時代…開発者は1人単位か数人が同じ場所で稼働するのが普通。要は、15年以上さかのぼると、IT や開発の世界はとってもシンプルだったと言えると思います。それから早送りすること2010年…僕も社会人になり…じゃなくて、インターネットの普及、開発手法の変化も多々あり、分散開発・分散システムが主流になり、今やクラウドですよね。開発者のニーズもそれに伴って変わってきている…はず。

どんな風にって?

リモートからのセキュアなコードへの接続・アクセス。
プロジェクトのより明確なトラッキング。
コードへの変更の自由なオーディット。
が、その情報を全て厳密に管理。
そして、何よりパフォーマンスの高く、信頼性の高いコードの管理。

 

Visual SourceSafe では、ここまでのことを実現することはできないんです。それが事実。
道具 (ツール) としては、それなりに良くなったと思いますが、2005 バージョンが最後であるのも事実。
ただし、ソリューションとしては、どうしても不十分なんです。

Team Foundation Server (TFS) が VSS の代わりかと言うと、厳密には違い、TFS は VSS の進化であると言うのが正しいでしょう。
そして、TFS 2010 のリリースからは、VSS ユーザーにインストールしやすく、使いやすく、そして現代開発において必要な機能を取り揃えていると、元製品担当として強く思っています。

 

TFS より VSS が良いところは??

端的に言うと、パフォーマンスが良い。信頼性が高い。拡張性があり、そのデプロイメントが容易である。
僕の TFS 関連のセッションでお話しを聞いたことがある方は、聞き飽きていると思いますが、TFS のバックエンド…いや、マイクロソフトのすべてのアプリケーション サーバーのバックエンドには SQL Server があります。そして TFS 2010 においては、パフォーマンスが更によくなった SQL Server 2008 をバックエンドに持ちます。Basic Install を実施するにしても、SQL Server 2008 Express を利用します。「へぇ～」と思うだけかも知れませんが、拡張性と言う意味では、SQL Server 2008 Express に格納される情報は簡単に SQL Server 2008 Standard や Enterprise に移行できるので、スケーラビリティは最高です♪

TFS を利用する容易性と言う面では、2005の時代からある Visual Studio に完全インテグレートされたインターフェースであること。
VSS との接続は VS からできていましたが、意外とソースコード管理の操作をするには VSS を個別に開き作業を実施する必要がありました。
Team Explorer (TFS クライアント) は VS  IDE の “I” に基づき、インテグレートされているので、ほぼ全ての操作を VS の中から実施できます (一部、管理者のみが実施できる作業はコマンドなどで実施できます)。

4GB のリミテーションもありません @ TFS。
VSS では、よくそこに苦しまされたのではないでしょうか?
データの陳腐化・破損、そしてそのデータのリカバリも、VSS では一苦労でした。
TFS は SQL Server が持つバックアップ機能を活用できるので、インスタンスごとのリカバリも可能。非常にフレキシブルなんですね。

 

VSS の構成は、基本的にはフォルダ共有。
権限の設定としては管理者・Read/Write と Read 権限を付与できましたが、Read ができれば実はなんでもできてしまったり…
もっと言うと、共有へのアクセス権限があれば、ぶっちゃけ全てのデータを削除することだってできちゃいます。

TFS と言うより、SQL Server であるから、このようなことは TFS では発生しません。 (サーバー自体に広範囲で権限を与えたら、当然できちゃいますけどね…汗)

 

VSS ではできなかった、厳密なソース管理・変更管理。
TFS では、いつ、誰が、どのコード部分をいかに変更したかの情報も見ることが可能。
そんなに必要? と思うかも知れませんが、共同で開発をしている時、どのコード部分を誰がどのような意図で書いたか・変更したかを知ることは意外と重要です。それを TFS を利用することで実装できる。

 

アトミックなチェックインが可能な TFS は、ビルドを壊すビルドをチェックインさせません。
VSS 時代では、一部だけのコードのチェックインなどができましたが、逆にそれは問題の種となっていました。
部分的にチェックインされ、ビルドが不十分なものを継続してコード変更することが発生してしまうようなことですね…
TFS ではそれはありません。

また、タイムスタンプなどをきちんと見て行かないと、どのコードとどのコードがセットとしてチェックインされたかも不明確。
TFS は全ての情報 (いつ、誰が、どのコードの、どの部分を、どの作業項目に合わせ、いかなる要求を満たすために、と言った情報) を保持しています。

 

TFS のブランチングは VSS のような共有モデルではなく、純粋なブランチです。
共有じゃないから、他のブランチでの変更に影響されることなく、ブランチ毎での開発が可能になります。
更に TFS 2010 では、ブランチの可視化もされており、可視化された情報にアクションを実施することも可能です。

image

 

バグ管理、メールでのアラート、シェルビング…
作業項目、要求定義に基づいて開発されているコードであるからこそ、バグもそれらの情報に紐づきます。
どの要求を満たす、どのコードが、どの作業項目でアサインされ開発され…どのテストを実行し、どのバグが発行され…誰がバグを発見・登録・発行したか…誰がそれをいつ直したか…そしてそれが改めてどの作業項目に紐づくか…すべての情報を通して管理できます。
状況のアップデートを自動的にメールで送信することも、非常に簡単です。

そしてさらには、作業中のコードをシェルビングすることで、ビルドに影響なく、作業中のコードを保存したり、他の開発者やテスターと共有することも可能なんですね。
ここまでくると、VSS からはほど遠い世界ですよね。

 

なんでそこまでやらなきゃいけないの?
聞かなければならないのであれば、貴方の開発プロジェクトは危うい状態にあるかも知れません…

 

VSS と TFS の操作性

image
VSS

image
TFS

パッと見は…非常に似ていますよね?
VSS が完全に使えないとは一度も言っていませんよね。要は、今の時代に必要な機能性がないと言うこと。
ですが、VSS の構成は良くできていましたので、TFS でもそれを応用しています。
だから、VSS ユーザーにとって TFS に移行するのはプラスでしかないんです。何故なら操作に関しては今までとそう変わるわけではないですから…TFS は完全に VS に統合されている…と言う違いくらいしか、感覚としては変わりはないかと思います。

 

操作ウィンドウも、基本は同じです。
チェックインや履歴の画面については、ほぼそのままです。
ですから、直感的に TFS で操作を行うことができるんです!!

 

なくなっちゃったの?

とは言っても、VSS の機能や操作がそのまま全てTFSにあるわけでも、操作が同じな訳でもないのは事実です。
殆どの機能は違った形で実装されていることが多いです。

例えばロールバックの機能などは、TFS 2010 ではコマンド ラインで実装されています。
シャドウ フォルダの機能はありませんが、タスクのスケジュールで TF Get を実行し共有にコピーをすることが可能です。

 

その他、なくなった機能などもありますが…理由はちゃんとあります (が、ここまで来て、書くのが面倒になってみたり…)

 

実際に移行はいかにして実行すれば良い?

Point-in-Time

このオプションは、VSS で Get Latest を実行し TFS に格納する方法です。シンプルかつ早い移行ではありますが、履歴情報は保持されません。VSS をアーカイブすることで履歴を確認できるので、楽な手段としてはこの手法が良いかと思います。実行方法は以下。

  1. Visual Studio の中で現在のバージョン管理プロバイダが Visual SourceSafe であることを確認します (Tools > Options > Source Control)
  2. 変更したいプロジェクトを Get Latest のオペレーションを利用して開きます
  3. ファイル > ソース管理 > ソース コントロールの変更を実施します
  4. ソリューションならびに全てのプロジェクトをアンバインドし OK をクリックします
  5. ソリューションを閉じ、変更を実行するプロンプトで「はい」を選択します
  6. TFS をバージョン コントロール プロバイダとして設定します (Tools > Options > Source Control)
  7. Source Control Explorer を開きます (View > Other Windows > Source Control Explorer).
  8. チーム プロジェクトが作成されていることを確認します (ない場合は作成)
  9. ファイルをプロジェクトにマッピングし、ローカル HDD へのマッピングも実行します
  10. 上記 9 でマッピングした箇所にソリューションをコピーします
  11. コピーされたソリューションを VS で開きます
  12. ソリューションを右クリックし、ソリューションをソース コントロールに追加します

以上でソリューションが TFS に追加され、Get Latest の状態から TFS を利用して開発を進めることが可能になります。
ね。簡単でしょ? w

 

FULL MIGRATION は結構ステップを踏む必要があり、長くなるので、又の機会に書ければ書きます。
取り敢えず、今回はここまでで… ( ^ー^)

9月のシンガポールは、今年の東京より全然湿気も少なく楽ですよぉ～～～♪

Comments

  • Anonymous
    September 13, 2010
    The comment has been removed