問題タブ [team-project]

ソース管理のみに 1 つの TFS プロジェクトを使用していて、別のプロセス テンプレートを使用してまったく別の TFS プロジェクトで作業項目を管理し、TFS プロジェクト間で変更セットを作業項目にリンクしようとしているクライアントがいます。

これが TFS で可能であることは知っていますが、この構成に伴う制限や問題が何であるかはわかりません。例: ビルド サマリー、レポートなど。

コードを新しい TFS プロジェクトに分岐し、コードと作業項目を 1 つのプロジェクトで一緒に管理したいのですが、上記の方法がどのように積み重なっていくかを知る必要があります。

新年に向けて Team Foundation Server のロールアウトに向けて、ソース管理構造の標準化に取り組んでいます。CodePlex で入手できるMicrosoft Team Foundation Server Branching Guidanceドキュメントを使用することから始めました。

提案された構造について私が持っているいくつかの特定の質問に対するフィードバックと回答を得たいと思っていました. TFS でのソース管理の構造化に関して言えば、選択できる "標準" が非常に多いため、実際には標準が存在しないことを学びました。

最初に、決定事項と使用法について概説し、説明します。

一般的な論理として、チーム プロジェクトには、単一の論理プロジェクト (エントリがない場合{Subproject}) または複数の関連プロジェクトを製品またはツール スイートの形式で含めることができます。3 つの主要なコンテナはDevelopment、 、Integration、および と呼ばれProductionます。

コンテナーのトランク内にDevelopmentは、フォルダー内の製品を構成する両方のプロジェクトのプロビジョニングがあり、Source対応する単体テストがTestsフォルダー内で利用可能です。マイナーな開発の大部分はトランクで発生し、分岐コンテナーとして機能するTrunkフォルダーの兄弟フォルダーを介して分岐が利用可能になります。Branches1 つ以上のソリューション ファイルが 内に存在しTrunk、そのレベルのブランチがソリューション、ソース、および単体テストを取得できるようにします。

TFS 以外のIntegration実装では「メイン」と呼ばれることが多いコンテナーは、変更セットを統合Developmentして安定したテスト可能なビルドを作成するためにのみ使用されます。Developmentテスト可能な製品が得られると、コンテナからのブランチとして最初に作成されます。このコンテナーからのビルドは、テスト環境と負荷テスト環境に使用されます。パフォーマンスの変化を監視できるように、テスト可能なビルドで負荷テストを含めることを選択し、不規則性の原因となった可能性のある変更セットを迅速に分離できます。

Productionプリプロダクションおよびプロダクション品質のビルドを作成するために使用されます。安定したビルドのリリースが推奨されると、最初はIntegrationコンテナーからのブランチとして作成されます。フォルダー内ではReleases、「リリースごとのブランチ」構造に従っており、スナップショットと分離を 1 か所で提供します。(たとえば、Release 1.1が本番前のビルドの準備ができている場合、安定したIntegrationコンテナーは構造内の新しいRelease 1.1フォルダーに分岐されますProduction/Releases。後続の RC および RTW/RTM もこのフォルダーに昇格されます。) 分岐構造も存在します。Branchesコンテナに見られるように。これにより、「ホットフィックス」、通常はリビジョン マーカー (Major.Minor.Revision) が可能になります。ブランチは現在のリリースから作成され、新しいリビジョン マーカーにマージされます。Release 1.1.1. Changeset は、受け入れ時にDevelopmentコンテナーに逆統合されます。Trunk

この構造は、堅牢性と複雑さのバランスが取れていると感じています。しかし、私がモデルに論理的に当てはめることのできないいくつかのしつこい質問があります。彼らです：

チーム ビルド-DevelopmentおよびIntegrationコンテナーは、最初はナイトリー ビルドとして開始され、最終的に継続的インテグレーション (CI) に移行します。Production コンテナーは手動でビルドされます。

• ビルド定義はどこに置くべきですか? 編集 - いくつかの回答に基づいて、TeamBuildTypes フォルダーがトランクに移動され、適切なコンテナーに分岐されました。ただし、これは新しい質問につながります（次のとおり）。

• TeamBuildTypes フォルダーを適切なコンテナーに配置するということは、すべてのビルド定義が適切なフォルダー間で再現されるということですか? たとえば、開発品質のビルドやテスト可能なビルドなどのビルド定義をすべて、構造全体のすべての TeamBuildType フォルダーに配置します。

ドキュメントの生成- Sandcastle を使用してドキュメントを生成します。具体的には、Sandcastle Help File Builderを使用して出力を管理しています。これにより、SFHB 固有の形式でプロジェクト ファイルが生成されます。

• 生成されたドキュメントをソース管理構造に保存する必要がありますか?

• ドキュメントはコンテナーごとに生成する必要がありますか?それとも、運用前および運用品質のビルドにのみ価値がありますか?

• 高速なローカル ビルド時間を維持するには、ドキュメントの作成をビルド定義で所有する必要がありますか?

• SHFB 固有のファイルはどこに置くべきですか? Source私の最初の考えは、それをおよびTestsフォルダーのピアとして配置することです。 Sourceとのピアであるという推奨事項に同意しTestsます。この変更を反映するために図を変更しました。

サードパーティのバイナリ

• バイナリ (コントロール、ライブラリなど) をソース管理に保存する必要がありますか?

• もしそうなら、それはそれ自身のチームプロジェクトであるべきですか?

一般的なドキュメント- 要件、設計ドキュメント、テスト計画など、生成されていないドキュメントは、ソース管理構造のフォルダーに反映されません。開発者や同僚とのいくつかの調査と議論の後、チーム エクスプローラーの組み込みのドキュメント フォルダーを使用すると、チーム プロジェクト ポータル内の構造が反映され、一部の (ビジネス) ユーザーは、ドキュメントを学習するための追加の複雑さを必要としないため、より多くの利点が得られます。 TFS のソース管理の側面。

より明確な図を提供するために、質問への回答が得られたら、構造を更新します。また、潜在的な変更に関連するその他のコメントも歓迎します。他に質問がある場合は、この投稿を必ず変更します。

編集:

• 説明。 フォルダーもコンテナーの下に存在しますSource。TestsIntegration

• Micah と Josh の両方が、サードパーティのバイナリに関する素晴らしい点を挙げました。問題に関する質問が追加されました。

• ドキュメントの生成は遅くなる可能性があります。ドキュメントの作成を特定のチーム ビルド タイプが所有する必要があるかどうかに関する質問が追加されました。

• 要件、設計ドキュメント、テスト計画など、生成されていないドキュメントに関連する解決策を追加しました。

• ビルド定義の TeamBuildTypes フォルダーに関連する解決策を追加しました。

• さまざまなフィードバックに基づいて、TeamBuildTypes フォルダーをトランク/ブランチ レベルに移動しました。

私たちの小さな開発ショップは、プロジェクトをVSSからTFSに移行することを検討しており、TFSと他のプロジェクトを比較しています（まだトリガーを引いていません）。私たちのソフトウェアショップの性質は、VSSに100以上のプロジェクトがあり、小規模なワンマンショープロジェクトから大規模な企業全体のアプリケーションにまで及びます。

移行中のプロジェクトをどのように構成するかを決定しようとしています。ほとんどの場合、すべてを1つのプロジェクトサイト/システムに配置し、各プロジェクトのルートからサブフォルダーを削除することにしました。

このタイプのセットアップでは、すべてのプロジェクトが同じポータル/プロジェクトスペースにあり、TFSが提供する多くの機能（バグ追跡、スクラムバーンダウン、レポート、ドキュメントストレージなど）が失われることが懸念されます。個々のプロジェクトチケット/アイテムを分離することは困難になります。

誰かがこれを経験したことがありますか？あなたの解決策は何でしたか？TFSを使い続けましたか？

会社には、少数のグループに論理的に分割できる多数の個別の小規模から中規模のアプリケーションがあるとします。

たとえば、BMW、マツダ、ホンダ、フォード ....、カワサキ、ハーレーなど、全部で数十、場合によっては数百のアプリケーションを持つことができます。

TFSには2つのオプションがあると思います：

1. アプリケーションごとに個別のプロジェクトを作成します。最終的に小さなプロジェクトが多くなり、制限に達する可能性がありますが、利点は、すべての作業項目、バグ、レポートなどを各プロジェクトに個別に割り当てて、各プロジェクトのポータルを持つことができることです。

2. プロジェクト「Cars」とプロジェクト「Motorcycles」を作成し、各プロジェクトの下に各アプリケーションのブランチを持つソース管理ツリーを作成します。これにより、構造が改善され、オーバーヘッドが削減されますが、ポータルとワークアイテム、バグ、レポートなどのリストを「ホンダ」と「BMW」で別々に持つことはできなくなりました。

何か不足していますか？プロジェクト数の TFS 制限に達するリスクを伴うプロジェクトのヒープを作成するオーバーヘッドなしで、作業項目の個別のリスト、小さなプロジェクトごとのバグの両方を持つ方法はありますか?

TFSでのソリューションのセットアップに関するフィードバックを探しています。現在、ソースセーフを使用しており、苦痛を伴います。幸い、ついにTFSに行きます。私たちはプロジェクトのコレクションを持っており、私はこれらを設定するための「最良の」方法を探しています。

コアは、他のアプリケーションのフレームワークを構成するサーバーソリューションとクライアントソリューションです。サーバーにはいくつかのWebサービスといくつかのライブラリのコレクションがあり、クライアントソリューションにはいくつかのライブラリといくつかのクライアントアプリケーションがあります。クライアントはサーバーと対話します。

このフレームワークに基づいて構築された個別のアプリケーションソリューションもあります。フレームワークソリューションのDLLのいくつかは、個々のアプリケーションで必要です。これらのDLL参照は頻繁に使用され、バージョンが同期しなくなることがあります。アプリケーション1は、FrameworkクライアントプロジェクトなどのライブラリDLLに依存しています。

問題を最小限に抑えるために、TFSでこれらのソリューションをどのように設定しますか？フレームワークソリューションのビルドでこれをどのように自動化しますか？私が探している結果は、アプリケーション1、2、および3がフレームワークのクライアントおよびサーバーソリューションからDLLファイルの更新バージョンを取得することを単純化し、フレームワークと個々のアプリケーションのリリーススケジュールで可能な限り同じバージョンを持つことです。

私の最初の考えは、フレームワークと各モバイルアプリ用の領域を持つ1つのチームプロジェクトを持つことです。フレームワークエリアには、クライアントとサーバーのサブエリアとそのサブエリアがあります。次に、フレームワークと同じレベルで、各アプリケーションが存在します。これがどれだけうまく機能するか、そして他のアプリケーションが最新のフレームワークDLLを自動的に取得するように強制する方法がわかりません。

• フレームワーク
• -サーバー
• ---サーバーWS
• ---サーバーライブラリ
• ---サーバーDataAccess
• -クライアント
• ---クライアントWS
• ---クライアントライブラリ
• ---クライアントDataAccess
• アプリケーション1
• アプリケーション2
• アプリケーション3

編集20091020：
フレームワークとアプリケーションの1つについてPMと話し合った後、これはソースコードをどのようにレイアウトするかについての彼の考えでした。これは私には理にかなっており、論理的に思えます。各アプリケーションとそのリリースの開発ブランチをかなり分離したまま、同じプロジェクトにまとめておくと、アプリケーションの要件をフレームワークなどで必要な変更に簡単にリンクできるようになります。

これについての考えは？あなたが見る長所/短所はありますか？

VS.Net 2010 Beta 2：チームプロジェクトが作成されると、ウィザードはプロジェクトのSharepointポータルを構成するかどうかの選択を提供します。チームプロジェクトにポータルが構成されているかどうかをプログラムで判断するにはどうすればよいですか。よろしくお願いします。

私はTFSに比較的慣れていないので、他の人が多くのプロジェクトがあるTFSの組織化に取り組んでいるのではないかと思います。たとえば、TFSプロジェクトをフォルダ内に配置できるかどうか、またはプレフィックス/サフィックスを使用できるかどうかを誰かが知っていますか？

私は、すべてのメンバーが自分のマシンに VS2008 をインストールしているチームに所属しています。ソース管理システムとして tortois svn を使用しています。自分のマシンに VS2010 をインストールして、彼らと連携できるソリューションはありますか? または、他のメンバーと連携するには VS2008 をインストールする必要がありますか? ありがとう。

TFS 2010でプロジェクトを論理的に分離する最善の方法を見つけようとしています。現在、3つの別々のプロジェクトがあります。

1. サーバー上で実行されるコアフレームワークプロジェクト
2. コアフレームワークdllを参照するコンソールアプリケーション。
3. コアフレームワークdllも参照するWebアプリケーション。

TFSは、プロジェクトをチームプロジェクトに分割します。これら3つはすべて実際には別個の「プロジェクト」ですが、最後の2つはフレームワークの.dll参照に依存しています。Javaの世界では、依存関係管理を設定して、コアフレームワークを構築し、会社の中央リポジトリに公開し、クライアントプロジェクトを個別にチェックアウトして、リポジトリ内のdllを参照するだけで、プロジェクトが中断しないようにすることができます。

TFSは依存関係を管理していますか？これらの3つのプロジェクトは、別々のチームプロジェクトに設定する必要がありますか、それとも同じプロジェクトに設定する必要がありますか？チームプロジェクト全体で構築できますか？

依存関係の問題を最小限に抑えながら、個別に作業できるようにパーティション化され、ビルドスクリプトがCIのすべてのプロジェクトにアクセスできるように、チームプロジェクトを設定するための最良の方法は何ですか？

当社では、開発プロセスに Team Foundation Server 2010 の使用を開始することにしました。

コレクションとチーム プロジェクトをどのように構成するかを決めるのに苦労しています。

合計 9 人の開発者がいて、全員が異なる時期に異なるプロジェクトに取り組んでいます。

私が読んだものの半分は、必要な数のコレクションを使用するように言っているようですが、残りの半分はコレクションの数を制限するように言っています。

必ずしも相互に作用しない複数のプロジェクトを作成/管理する場合、どのようなアプローチをとっていますか? 別々のコレクションに入れるのが最善ですか、それともコレクションの数を少なくしておくのが賢明ですか? どんな助けでも大歓迎です。