7

TFS分岐構造のセットアップについてサポートが必要です。

現在のシナリオは次のとおりです。アプリケーションはSaaSであり、複数の「リリース」ブランチが同時に必要になると思います。

TFS分岐ガイドIIIを読むと、「高度な」分岐モデルが必要になると確信しています。

まず、「メイン」ブランチを作成します。このブランチには、現在のアプリケーションが格納されます（Visual Source Safeから取得しています）。そこから「開発」ブランチを作成し、今はそのままにしておきます。また、現在の一連の変更を含む新しい「Service Pack」、「Hotfix」、および「ReleaseA」ブランチツリーを作成します。次に、QAチームに「リリースA」ブランチを分析させ、合格した場合は閉じて（読み取り専用）、「メイン」にマージします。

これまでのところ、それはすべて問題なく、ダンディです。

問題が発生するのは、QAサイクルに約1か月かかることです。その間、開発者には、独自の「サービス」を持つ「リリースB」の新しい「サービスパック」および「開発」プロジェクトに取り組んでもらいたいと考えています。 「パック」、「ホットフィックス」、および「リリースB」のブランチ。

これは、一度に2つのリリースブランチが実行されることを意味します（もちろん、よりスマートな方法がない限り）。

質問：「開発」プロジェクトが完了する前に「リリースB」が作成された場合、「リリースA」の「ホットフィックス」が必要です。その「ホットフィックス」を「リリースA」から「リリースB」に伝播するにはどうすればよいですか。その間に完了する「開発」プロジェクトをピックアップしますか？

4

2 に答える 2

4

http://blog.hinshelwood.com/guidance-a-branching-strategy-for-scrum-teams/の図を見てください。また、ブログ エントリ全体を読んでください。ソース: Martin Hinshelwood のブログ

あなたの「開発」プロジェクトは、図では「スプリント 1」と「スプリント 2」と呼ばれています...スプリントがリリースからどのように分離されているかに注意してください。マージを経由しないと、それらに到達することはできません。

于 2011-08-16T03:25:25.300 に答える
2

質問: 「開発」プロジェクトが完了する前に「リリース B」が作成された場合、「リリース A」の「ホットフィックス」が必要です。その間に完了する「開発」プロジェクトをピックアップしますか?

簡単な回答:説明されている特定のシナリオでは、リリース A からメインを介して安全にマージし、リリース B に戻ることができると思います (はい、これは 8 月 16 日のコメントで Geoffrey McGrath が述べたことと同じです)。ブランチを作成した後、メインからリリース ブランチへの FI マージを実行しないでください。ただし、メインに存在する唯一の変更がホットフィックスであることを確認できれば、マージは目的を安全に達成するはずです。ただし、これは、「Release B Servicing」が分岐されて以来、他に何もマージされていないクリーンな Main 分岐があるという非常に疑わしい仮定に基づいています。続行する前に、この仮定を非常に注意深く確認してください。

ダーティ メインの回避策 - チェリー ピッキングまたはベースレス マージ:メインに他の変更がある場合は、メインから特定のホットフィックスを "Release B Service Pack" にチェリー ピック マージできます。もう 1 つのオプションは、"Release A Servicing" から "Release B Servicing" に直接ベースレス マージを実行することです。これにより、メインの他の変更がバイパスされます。(Dev ブランチがホットフィックスを取得できるように、この修正をメインでマージする必要があります。) チェリー ピック マージとベースレス マージは、通常のマージよりもリスクが高いことに注意してください (そのままでは十分に注意が必要です)。それでも、より良い解決策が存在しない特定のシナリオでは有効なオプションです。

Meta-answer#1:図を描くと、元のブランチから最終的な目的地までの変更を追跡するのに役立ちます。Cherry-pick には特別な表記はありませんが、baseless merge は点線の矢印で構いません。紙の上で機能する場合 (そして、メインとの他のすべてのブランチのやり取りを説明した場合) は、機能するはずです。

メタ回答 #2:上記で質問に完全に回答していない場合は、 http://tfsbranchingguideiii.codeplex.com/discussionsフォーラムを読んで、この特定のリクエストを相互投稿することをお勧めします。Bill Hays は通常、そのフォーラムで非常に反応がよく、あなたの質問は間違いなく TFS ブランチ内の修正プログラム管理を指しています。

ご参考までに：

私のチームは、SaaS と同様の課題に直面するいくつかの SOA (サービス指向アーキテクチャ) プロジェクトに取り組んでいます。1 か月の QA サイクルは複雑な作業です。

私は Martin の記事がとても好きです (以下にもう一度引用します)。レビューする価値のある追加の記事が 2 つあります (両方とも、素敵な TFS 分岐ガイドの図を補強するためのきれいな写真があります)。ただし、3 つの記事はすべて、ホットフィックス リリース ブランチ管理ではなく、開発ブランチ管理に焦点を当てています (以前の回答の図と同じ)。

  1. ガイダンス: スクラム チームの分岐戦略- Martin Hinshelwood 2010.04.14 - スクラム チームが 2 つのスプリントで作業するときの基本的な「リリースごとの分岐」戦略の優れたウォークスルー (素晴らしい図付き)。
  2. スクラムの分岐- Bill Heyes (ALM Ranger) 2011.01.18 - 優れたスクラム チーム図とスケーリング分岐。
  3. 開発中の複数のリリースに取り組んでいる並行機能チーム。本番環境への毎月のリリース。- Bill Heyes 2011.01.14 - 分岐シナリオ (3 つの Web 開発チーム + 1 つの製品環境) と非常によく似ています。ガイダンスは、チーム別ブランチ + リリース別ブランチです。

楽しみ！-ゼファン

于 2011-08-18T23:52:18.703 に答える