2

複数の開発チームによる TFS および複数のアプリケーション (一部は COTS、一部は内部開発) の分岐とマージに関するガイダンスを探しています。現在、月次リリース ウィンドウを使用していますが、四半期ごとに予定されていることに注意してください。また、eFixe および非リリース開発の取り組み (つまり、ウィンドウ外で実装する必要がある規制の変更) をサポートできる必要があります。現在の調査に基づいて、次の 2 つのオプションの調査に注力しています。

オプション 1) 各アプリケーションが MAIN、RELEASE、および PRODUCTION ブランチを持つメジャー アプリケーションごとのリリース ブランチ (PRODUCTION ブランチは、eFix とオフサイクル変更をサポートする eFix ブランチをサポートします)。

オプション 2) 組織全体のリリース ブランチ - MAIN、RELEASE、および PRODUCTION ブランチにはすべてのアプリケーションが含まれます。

4

1 に答える 1

3

ここにいくつかの役立つ分岐の提案があります。

Visual Studio Team Foundation Server の分岐およびマージ ガイド

あなたの質問に対するWRT私の見解は

オプション 1) 個々のアプリケーション リリースの分岐

これは、相互に依存関係がある場合、アプリケーションにあまり多くない場合です。

長所：

  • ビルドが速くなる
  • Cherry Pick デプロイ コンポーネントの柔軟性が向上
  • 少しずつ頻繁にビルドしてデプロイできるため、継続的インテグレーション ビルドに適しています。
  • 品質ゲートに基づいて、個々のアプリケーションをサインオフしてロックします
  • 重要な修正の再展開が容易
  • より小さく、おそらくより頻繁にマージします

短所：

  • ビルド/デプロイ スクリプトを維持するための管理オーバーヘッドの可能性
  • アプリケーションの依存関係がある場合、コンポーネントを厳選するときにリスクが生じる可能性があります
  • アセンブリのバージョンとラベルを維持するための堅牢な展開フレームワークが必要です。
  • 展開時に複数の展開アセット リソースが関与します (1 つの展開パッケージではなく)。

オプション 2) すべてのアプリケーションのリリース分岐

長所：

  • いつでもすべてのアプリのバージョンを簡単に識別できます。
  • Teardown とフル デプロイを使用してデプロイできます。
  • 管理するビルド スクリプトとデプロイ スクリプトの削減
  • 管理するデプロイメント資産リソースを減らします。
  • リリース レベルのマージ/変更セットの追跡/視覚化が容易

短所：

  • ビルドにはさらに時間がかかる場合があります
  • アプリケーションが目的に適合しない場合、またはコードのフリーズ/サインオフ後にバグが含まれている場合、リリースの柔軟性が低下する
  • コンポーネントのチェリーピックが難しい
  • 生産上の重要な修正は、再構築と展開に時間がかかる場合があります
  • 展開フレームワークに応じて、ロールバックはオール オア ナッシング
  • マイナーな修正の展開には、完全な回帰テストが必要になる場合があります (QA コントロールによって異なります)。
于 2012-10-30T10:22:13.473 に答える