TFSのプロジェクト間での共有コードのマージと分岐

Question

私は現在、asp.netアプリケーションをソースセーフからTFSに移行しています。現在、コアライブラリ（サービス、ビジネスロジック、エンティティ、データアクセスなど）を共有している3つまたは4つの非常によく似たアプリケーション（電子商取引といいます）があります。

アプリケーションでは、私は（それが収まる場合）、コードの共有、代わりに設定枝を停止したい似ているが同一ではないので、1つのアプリは機能がなど

を取得することはありません他人を設定してしまうかもしれませんですアプリケーションAのコアライブラリで何かを変更した場合、変更を自動的に取得するのではなく、他のブランチとマージする必要があります。これはトランクから更新したときに驚きを避けるために突然コアが別のプロジェクトで変更され、このプロジェクトが何らかの形で中断します。

これをTFSでどのように設定するべきですか？他のすべてのコアの親であるプロジェクトで直接使用されていない「メイン」コアを用意する必要があります。そのため、あるコアからそのコアに変更をプッシュし、それを他のコアに配布できますか？それは理にかなっていて、TFSでセットアップするのは簡単でしょうか？

Answer 1

お客様のご意見をお待ちしておりますので、Feature branchesのCodePlexウェブサイトでお読みください。

シナリオ4 - このシナリオでは機能
ための支店は、あなたが 開発ブランチを作成し、 ブランチで作業を行い、その後、あなたのメインのソースツリーに戻ってあなたの仕事 をマージします。あなたは 開発ブランチを組織化する製品の機能に基づいて に基づいています。

マイチームプロジェクト

 Development -> Isolated development branch container 
     Feature A -> Feature branch 
      Source 
     Feature B -> Feature branch 
      Source 
     Feature C -> Feature branch 
      Source 
     Main  -> Main Integration branch 
      Source 

我々はALOS近い将来にTFSにSSから移動している：以下 は、機能開発のための分岐 を示す物理的な図です。

私が気づくように、私たちはSSリポジトリをオンラインにして、TFSに新鮮に始める予定です。私たちのフレームワークは、おそらくTFSで独自のプロジェクトを取得します。プロジェクト特有のユニットは時々合併する必要があります。

---

具体的な状況によって、リポジトリを構成する方法が異なります。すべてのブランチシナリオには、それぞれの利点と欠点があります。あなたは同時ホットフィックス

が必要ですあなたはサービスパック

は見てみましょう必要がありますかどのように多くの開発者が

専念していますどのように多くの開発者

プロジェクト

• CodePlex branching guideあなたのTFS構造に関する情報に基づいた決定を下すために必要なすべての情報については、 cheat sheetsを印刷して、壁に固定してすぐに参照できます。あなたのブランチ計画に実行する前に

  、この注意 メッセージに 注意を払う - あなたが作成するすべてのブランチが ので、あなたがそれから、いくつかの 値を取得することを確認し、コストを持っていません。 TFSの ブランチングのメカニズムは、 右クリック分岐コマンドに簡略化されています。 しかし、分岐の総コスト は、コード速度を遅くして にマージすると、マージ競合が発生し、さらに テストが高価になる可能性があります。

Answer 2

私は、あなたが本当にあなたの「コピー」を別のチームプロジェクトにする必要があるかどうかを調査していると仮定しています。 「チームプロジェクト」のTFSコンセプトは、非常に大きな高レベルのコンテナであることを忘れないでください。ほとんどのITショップが「プロジェクト」と考えるものと同じではありません。 「Microsoft Vista」または「Office 2007」をプロジェクトとして考えてください。チームプロジェクトの意味では「XYZ社の売掛金管理システムの新リリース」とは言えません。

TFS用に1つのチームプロジェクトを決定したクライアントがあります。これには何も問題はありません。それは本当に多くの状況で最高のシナリオです。

アプリケーションのコピー間に非常に強いアイソレーションが必要な場合（おそらく、別個のクライアントであり、非常に強力なセキュリティ分離が必要です）、別個のチームプロジェクトが必要です。

これまで述べたように、アプリケーションのインスタンス間でコードを共有する必要があります。私が強くお勧めする最初のことは、 "切り取りと貼り付け"の共有から離れさせることです。私は本当に別々のソリューションに共有コードを分離し、そのためのバイナリを生成しようとするだろう（おそらくあなたはすでにこれをやった！）

これはCodePlexにTFSで覆われている：http://tfsguide.codeplex.com/

私がきたもう一つのアプローチいくつかのクライアントのために行われます - 共有されたコードを含むチームプロジェクトを持つことです。 "Build"は共有コードのバイナリを作成し、 "Deploy"はそれらを単に "既知の場所"（ビルドマシンのUNC共有）にコピーします。

"フレームワーク "では、単に" AdditionalReferencesPath "Itemグループを使用して、その既知の場所の場所を含めました。

さらに - このツール：http://tfsdepreplicator.codeplex.com/が役に立ちます。これにより、「フレームワーク」ソリューションが構築されるたびに、「コンシューマー」プロジェクト用にビルドが自動的に開始されるようになります。

Answer 3

簡単な答えは、「TFSプロジェクト」を1つだけ設定し、異なるプロジェクトを簡単に整理することです。個々のアプリケーション、および各共有ライブラリを、その1つのTFSプロジェクトの下の別個のフォルダとして保存します。別の方法としては、個々のアプリケーションに共有ライブラリの特定の（バイナリ）ビルドを含めることです。そうした場合、各アプリケーションを独自のTFSプロジェクトに編成できます。つまり、TFSを使わずに変更をマージしたり、コマンドライン（およびブートするためのいくつかの明白なコマンド）。

Answer 4

私は同じ情報を決定しようとしていた、CodePlexの上でこのガイドでは、用語と異なる分岐ワークフローのアプローチだけでなく、チートシートが含まれています

http://vsarbranchingguide.codeplex.com/releases

最適です。