私は現在、TFS 2010 をソース管理およびバグ/リリース管理ツールとして展開するためのビジネス ケースを作成しています。
現在、バグ追跡ソフトウェアには OnTime を使用し、SCM には Subversion を使用しています。
TFS 2010 が OnTime より優れている点は何ですか?
これまでにいくつか考えてみましたが、回答をお待ちしております。
前もって感謝します。
TFSは、私がこれまでに使用しなければならなかった不幸なバージョン管理システムの中で、最も直感的でないバージョン管理システムの 1 つです。生の機能リストと機能の点で、OnTime (および他の同等のシステム) よりも多くの「箇条書き」の利点があるかもしれませんが、重要な要素は、作業プロセスに適合できるかどうかです。
TFSに関する私の経験では、 TFSを自分の作業方法に適応させることは不可能であるか、正当化するのが難しすぎるため、 TFSの作業方法に適応する必要があります。
私たちは最近、SVN と手動のバグ追跡システム (Excel スプレッドシート) で構成されたシステムを置き換えるために、いくつかの代替案を検討しました。On-Time は評価されましたが、費用がかかりすぎて複雑すぎると判断されました。
最終的に、引き続き SVN を使用することを選択しましたが、リポジトリ構造を大幅に修正 (簡素化) し、SVN を FogBugz 問題追跡システムと組み合わせることにしました。これら 2 つのシステム間の統合は、かなり初歩的な「すぐに使える」ものでしたが、私たちが望むより緊密なレベルの統合を達成するために、私たちの側で少し努力するだけで済みました。以前のTFSロールアウトの経験よりもはるかに労力がかからないことは確かです。
当社の SVN/FogBugz システムは、FinalBuilder ビルド自動化スイートにも統合されました。
その結果、私たちの作業慣行に完全に適合するだけでなく (それを実現するためにシステムを統合する手段を考案したため)、作業慣行の進化に合わせて無限に適応できるシステムが実現しました。
それは、チームの規模と、ソース管理に何を求めているかによると思います。
私は数年間、Perforce と一緒に bugzilla を使用しており、非常に小さなチーム (2 ～ 3 人) で作業している間は、どちらもそれぞれの点で非常に優れていることがわかりました。慣れるのに時間がかかったいくつかの小さな特異性から。
私は最近、TFS が広範囲に使用される新しい仕事に移りました。この会社には 4 つの主要なチームがあり、それぞれに 10 ～ 12 人の開発者がおり、そのレベルの下にさらにプロジェクト チームに分割されています。TFS が真に輝くのは、この種の環境です。私の見解では、最大の利点は次のとおりです。
1) Visual Studio との統合 - 開いているウィンドウが少なくなるだけでなく、作業がスピードアップし、作業が楽になります。作業中にVSが自動的にファイルをチェックアウトする（ロックレス編集による偶発的なチェックアウトの問題なし）、ローカル+ TFビルドを同期できる、ローカルバージョンを以前のものとすばやく比較できるなどのこと..はい、取得できます統合するサードパーティのプラグインはありますが、このレベルではなく、同じ安定性があります。
2) 通信機能 - Live Messenger との統合などの単純な機能 (TFS を正しく構成している場合) は、大規模なチームに最適です。WLM を使用して、オフィス全体でコミュニケーションを取り、共同作業を行います。簡単な質問をする必要があるたびに他の人のところに行くよりも簡単です。
3) ビルド/チェンジリストをタスクにリンクする - はい、他の SCM もこれを行いますが、これも非常に優れた統合された方法で行われます..TFS にとって特別なことではないと思いますが、個人的には、これを追跡する方法が気に入っています。
4) マージ/ロックレス編集の容易さ。私は他のいくつかのマージ ツールの経験があり、TFS のツールは十分にうまく機能し、同時編集後のマージが非常に簡単になりました。この点では perforce に非常に似ていますが、他の開発者が取り組んでいる編集で潜在的な問題を引き起こす可能性がないことがわかっている小さな編集に使用する、通常は非常に効果的な自動マージ ツールも備えています。
5) 自動ビルド/ビルド管理。相互に依存する 20 ～ 30 のプロジェクトを含むいくつかの大規模なソリューションを使用する場合、これは天の恵みです。何かが変更された場合は 20 分ごとにビルドをキューに入れるように設定されており、変更が発生すると履歴ログにリストされます。ローカル ライブラリを更新する必要がある時期を簡単に確認できます。
ビルド管理以外の構成の経験はありませんが、これが TFS の最悪の部分であると聞いています..すべてを正しく実行するのは少し面倒です.
したがって、それをビジネス ケースに変換すると..大規模なチームや複数のチームを持つ Microsoft ソフトウェア ハウスである場合、上記の機能の結果として得られる時間の節約と生産性の向上は、投資する価値があると言えます。それを設定する際に。ほとんどの場合、MSDN サブスクリプションを持っているため (CAL の問題があるかもしれませんが、よくわかりません)、無料で使用できるため、最大のコストはユーザーのトレーニングと構成に費やされます。
まず、あなたの主な関心事は何か、 TFS の展開によって解決しようとしている問題は何かを検討することをお勧めします。
バージョン管理に関しては、バージョン管理ツールに関する Martin Fowlerのブログ投稿と、バージョン管理システム調査のフォローアップ結果をお勧めします。確かに、これは主題の主観的な見方である可能性がありますが、かなり人気があるようです. TFS は、他のバージョン管理システムと比べて明らかに劣っています。
私は現在 TFS2008 を使用しており、SourceSafe と IBM ClearCase/ClearQuest から移行しました。TFS が以前のどのツールよりもはるかに優れていることは間違いありませんが、それでも重大な欠点があり、新しいバージョンではそれらに部分的にしか対処できません。
あなたが提起した個々のポイントに対処する：
TFSの利点については、おそらく言及します
完全な TFS インストールを展開するのにかなりのコストがかかることを考えると、このソリューションが他のソリューションでは得られない実際のビジネス上のメリットを真剣に検討したいと思います。
TFS についてはよくわかりませんが、OnTime の UI は直感的ではありません。また、バグとタスクに異なるフィールドがあるのも好きではありません。もちろん、いつでも独自のフィールドを追加できますが、デフォルトのレイアウトをすぐに使用できるはずです。
タスクであっても「バグ」ばかりで終わってしまいます。
私はそれが悪い製品だとは言いませんが、現在 TFS がバグ追跡用により優れた UI を持っている場合 (私がそれを使用しなければならず、嫌いだった 4 年前にはありませんでした)、これは TFS の議論になるでしょう。
SVN を取り除きたいと聞いて申し訳ありません。それは難しい決断です。
Axios OnTime のライセンスについてはよくわかりませんが、MSDN サブスクリプションをお持ちの場合、追加料金はかかりません。ブログ記事はこちら
私はバージョン管理のためだけに TFS 2008 を使用してきました。これは VSS からの優れたアップグレードですが、私たちがやろうとしていることのいくつかは、期待されているものと正確に一致していません。そうは言っても、私はこれらのギャップを埋める簡単な小さな Web アプリを作成しました。API を使用して開発するのは非常に簡単で、特定のタスクを支援するアドオンがたくさんあります。
おそらくあなたが聞きたい答えではないでしょうが、私はTFSに対してビジネス上の主張をするために最善を尽くします。
いずれにせよ、私の一般的なアドバイスは、非常に小さいが実際のプロジェクトで自分で（または小さなチームで）試してみることです。おそらく、一度だけ必要なツール、または簡単に破棄できるコードです。小さいので別のシステムに移行しました。実際にシステムを使用するのに勝るものはありません！
OnTime と Subversion を使用しました。TFS をバグ トラッカーとして使用したことはありませんが、ソース管理には使用しました。そのソース管理部分は、基本的には古い Visual SourceSafe のままです。現在 Subversion を使用している場合は、ファイルの名前を変更する必要があるとき、または絶対に禁じられていることですが、ファイルを削除してから同じ名前のファイルを作成する必要があるときはいつでも頭を悩ませることになるでしょう。分岐やマージは気にしないでください。ソース管理システムがいかに原始的で壊れやすいかを投稿で伝えるのは難しいです。チェックインも削除もできないファイルや、意味のないエラーで立ち往生していることに気付いたときに、私が何を意味するかがわかります。Subversion が完璧というわけではありませんが、VSS より 10 年先を行っています!
私が簡単に遊んだだけの TFS のワークフロー部分は、私には非常に「重い」ように思えます。つまり、実際にはユーザーをそのワークフローに制限し、不要なことが多い多くの手順を必要とします。これは役に立ちますが、簡単に邪魔になることもあります。優れたシステムは、必要なときにワークフローを提供しますが、邪魔になるだけの場合はバイパスできます。OnTime を使用したとき、その比較的目立たないワークフローでさえ、多くの場合、価値があるよりも面倒であることがわかりました. もちろん、これはすべてあなたの状況の詳細に依存します。現在、OnTime ワークフローをどのように使用していますか? また、OnTime が提供していない TFS に何を求めていますか?
変更セットをバグにリンクすることは、Subversion でも行うことができます。いくつかの拡張メカニズムをサポートしています - 詳細は覚えていませんが、FogBugz はそれを使用しています (OnTime の後に切り替えました)。ビルドへのリンクは、単純な svn tag コマンドをビルド スクリプトに追加することで実行できます。Visual Studio の統合はVisualSVNで行うことができます。
コストも TFS の大きな欠点です。特にそれがどれほどうまく機能するかを考慮すると、それは非常に高価です。はい、開発者ごとに MSDN サブスクリプションが必要な場合は「無料」ですが、TFS がなければ必要ですか? Subversion は無料です。OnTime と FogBugz は、はるかに手頃な価格です。
TFS に対して強くお勧めします。以前、クラッシュしたインスタンスからソース コードを復元しようとしたことがありますが、数日後にあきらめたため、ソース コードが失われました (= VCS が行うべきことの 1 つを実行できませんでした)。もちろん、私が何か間違ったことをした可能性もありますが、復元ガイドが 2 マイルにも及ぶ場合、すべてを正しく行うことは容易ではありません。
今は Subversion/Trac を使っていますが、これで仕事は完了です (Trac でワークフローをカスタマイズするのはとても簡単で、TFS と比べると楽しいものではありません)。
当分の間、TFS は避けてください。
私は SVN + FinalBuilder を使い続け、FogBugz または CounterSoft Gemini のどちらかを選択します。