web-dev-qa-db-ja.com

Team FoundationServerのソース管理構造

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

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

まず、決定と使用法の概要と使用法について説明します。

$/                                                
    {Team Project}/                               
        {Subproject}/                             
            Development/                          
                Trunk/                            
                    Source/
                    Tests/
                    Sandcastle/
                    TeamBuildTypes/
                        {Build Name}/
                Branches/
                    {Branch Name}/
                        Source/
                        Tests/
                        Sandcastle/
                        TeamBuildTypes/
                            {Build Name}/

            Integration/
                Source/
                Tests/
                Sandcastle/
                TeamBuildTypes/
                    {Build Name}/
            Production/
                Releases/
                    {Release Version}/
                        Source/
                        Tests/
                        Sandcastle/
                        TeamBuildTypes/
                            {Build Name}/
                Branches/
                    {Branch Name}/
                        Source/
                        Tests/
                        Sandcastle/
                        TeamBuildTypes/
                           {Build Name}/

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

Developmentコンテナのトランク内には、製品を構成する両方のプロジェクトのプロビジョニングがSourceフォルダーにあり、対応する単体テストはTestsフォルダーで利用できます。マイナーな開発の大部分はトランクで発生し、分岐はTrunkフォルダーの兄弟であるBranchesフォルダーを介して利用できます。これは、分岐コンテナーとして機能します。 1つ以上のソリューションファイルが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のような新しいリビジョンマーカーにマージされます。変更セットは、受け入れられると、DevelopmentコンテナのTrunkに逆統合されます。

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

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

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

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

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

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

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

  • 速いローカルビルド時間を維持するために、ドキュメントの作成はビルド定義によって所有されるべきですか？

  • SHFB固有のファイルはどこに保存する必要がありますか？私の最初のインクリングは、それをSourceフォルダーとTestsフォルダーのピアとして配置することです。SourceとTestsのピアであるという一般的な意見に同意します。この変更を反映して図が変更されました。

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

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

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

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

質問への回答が得られたら構造を更新して、より明確な画像を提供します。また、変更の可能性に関するその他のコメントも歓迎します。他にご不明な点がございましたら、必ずこの投稿を変更させていただきます。

編集：

  • 説明。 SourceおよびTestsフォルダーもIntegrationコンテナーの下にあります。

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

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

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

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

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

version-controltfsteam-project
47
Joseph Ferris

SandcastleファイルをSourceand Testsのピアとして配置するというあなたのアイデアが好きです。ドキュメントフォルダーを追加します。このフォルダーには、Sandcastleファイルと、オプションで実際のドキュメントが含まれます。

確かに意見の違いがあり、私はこれに反対票を投じると確信しています（私は以前に行ったことがあるので）。生成されたドキュメントをTFSに配置する理由はいくつかあります。

  1. リリースごとにドキュメントが必要になり、TFSを使用することは、ドキュメントを正しい場所に保持するための簡単なアプローチです。
  2. TFSを使用して保存すると、誰もがドキュメントの入手先を知ることができます。

私がいつも苦労していることの1つは、サードパーティの依存関係がどこにあるのかということです。それらはソースの下に属しているため、各プロジェクトに含まれている可能性がありますが、プロジェクト間で共有したい場合は、新しいトップを追加できます。レベルノード。

編集

私のバイナリの場合、私は通常、

$/ThirdParty/Company/Product/Version/Src（オプション）

だから例えば私は持っています

$/ThirdParty/Microsoft/EntLib/3.1 4.0 ComponentArt/WebUI/2008.1/Src

ソースを追加するのが好きです。嫌いなCAのソースにパッチを適用する必要がありましたが、サードパーティがバグを修正しない場合は、これに頼る必要があります。

6
JoshBerke

素晴らしいレイアウトと説明。私はまったく同じ問題に苦しんでいます。私は非常によく似た構造になってしまいました。鉱山はわずかに異なります。

Development/
   Trunk/
      Binaries/  -- Shared libraries
      Source/
      Test/
      Docs/      -- Documentation
TeamBuildTypes/  -- Build definitions
  • バイナリフォルダを追加すると、すべてのプロジェクトが共有ライブラリを参照できるブランチ内の1つの場所を持つことができます
  • ドキュメントをここに置いて、特定のブランチと一緒に移動できるようにします。
  • ビルド定義は、すべてのブランチに対して1つの場所で把握できるため、開発レベルにありますが、間違いなくブランチレベルにある可能性があり、より理にかなっている可能性があります。

バイナリ（コントロール、ライブラリなど）をソース管理に保存する必要がありますか？もしそうなら、それはそれ自身のチームプロジェクトであるべきですか？

それらは間違いなくソース制御されるべきだと思いますが、彼ら自身のチームプロジェクトにそれらを入れる理由は見当たりません。注意すべき問題の1つは、何らかの理由でTFSがバイナリファイルをわずかに異なる方法で処理することです。ソース管理でバイナリを更新したときに問題が発生しましたが、他のマシンで「GettingLatest」を実行してもファイルは更新されません。 「特定のバージョンを取得」を実行し、その特定のファイルの「変更されていないファイルを上書きする」オプションをチェックする必要がある場合があります。

4
Micah

TeamBuildsフォルダーをトランクの下に配置する必要があります。これはTFS2005では不可能でしたが、Microsoftは2008年に修正しました...

これは、ビルドが新しいバージョン（たとえば、新しいパッケージスキーム、異なるテストなど）で変更され、古いメンテナンスリリースと互換性がなくなる可能性があるためです。そのため、チームビルドをコードのバージョンと組み合わせる必要があります。

このように、1.0バージョンをリリースして、Releasesフォルダーの下に置いたとします。開発トランクでv2.0で作業しているときに、ビルドしてパッチを発行することができます（ビルドの変更が必要になる場合があります）

3
Eran Kampf

バイナリの場合-明らかに、バージョン管理下にある必要があるバイナリは、自動ビルドの一部として「ビルド」していない「サードパーティ」アセンブリだけです。ソースがバージョン管理下にある独自のライブラリがある場合など、ビルドや同期などのさまざまな戦略を検討する必要があります。

次に、それらをJoshのように編成し、分岐を使用して、ソリューションツリー内の.NETProjectフォルダーのピアである_ExternalReferencesフォルダーにバイナリを「コピー」します。 TFSバージョン管理は「デルタ」のみを格納するため、これはサーバー側で非常に効率的な方法です。したがって、多くのプロジェクトにわたるこれらのバイナリの基本的にすべての「複製」は、基本的に「ポインター」のようなものです。

3
fuzzbone