新年に向けて Team Foundation Server のロールアウトに向けて、ソース管理構造の標準化に取り組んでいます。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フォルダーの兄弟フォルダーを介して分岐が利用可能になります。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。TestsIntegrationMicah と Josh の両方が、サードパーティのバイナリに関する素晴らしい点を挙げました。問題に関する質問が追加されました。
ドキュメントの生成は遅くなる可能性があります。ドキュメントの作成を特定のチーム ビルド タイプが所有する必要があるかどうかに関する質問が追加されました。
要件、設計ドキュメント、テスト計画など、生成されていないドキュメントに関連する解決策を追加しました。
ビルド定義の TeamBuildTypes フォルダーに関連する解決策を追加しました。
さまざまなフィードバックに基づいて、TeamBuildTypes フォルダーをトランク/ブランチ レベルに移動しました。