2

スタンダード ブランチ プランに関して非常に簡単な質問があります。

ブランチ、FI、RI などは理解しています。よく理解していないのは、サービス ブランチを実際に使用する方法です。

私の理解では、リリースの時期になると、Main -> R1.SP1 に分岐し (たとえば、これが私の最初のリリースであると仮定します)、すぐにR1.SP1 を R1 に分岐します。次に、R1 を読み取り専用に設定します。これは私が完全に理解し、気に入っています。

R1.SP1、R1.SP2、R1.SP3 はいつ、どのように作成されるのですか?

RI SP1 をメインに戻し、時間の経過とともにメインを SP2/3/n に分岐しますか?

別の言い方をすれば、これらの将来の SP には、独自のリリース/展開の変更がどのように取り込まれますか?

たとえば、顧客が R1 のバグを報告した場合、この変更を行うためにどこからコードをチェックアウトし、変更/修正されたコードをどこにチェックイン/コミットしますか? SP1 ブランチにチェックインしますか? (R1 ブランチは読み取り専用であるため)。じゃあ何？ 

R1 の将来の SP を作成するための継続的な開発がどこで行われているのか、また、これらの SP は独自のリリース/展開のためにどのように作成および準備されるのでしょうか?

非常に単純なステップバイステップのシナリオの例が最も役に立ち、高く評価されます。

私の質問が明確でない場合はお知らせください。修正するために最善を尽くします。

4

1 に答える 1

2

TFSスペシャリストではありませんが、私が読んだのは次のとおりです。

  1. 開発者は、変更の対象となるリリースビークルに基づいて、一度だけチェックインする必要があります（つまり、修正プログラムは製品HOTFIXブランチに入ります）。
  2. ベースレスマージの必要はありません。MAINリリースビークルに基づいて階層ブランチ構造を作成することにより、に戻る自然なマージパスを作成します。
  3. 回帰のリスクを減らします。MAIN->SP->とブランチの間に親子ブランチ関係を作成することにより、HOTFIX変更は自然に将来のリリースにマージされます（つまり、途中でブランチにHotfixesマージされます）。将来のリリースでのバグリグレッションのリスクが軽減されます。SPMAIN

リリースブランチが作成された後、からの変更をリリースブランチにマージ（ ）しMAINないでください。変更は、一方向でからにマージする必要があります。また、バグ修正が後続のリリースで一貫性を保つように 、変更は常に中間ブランチ（つまり、-> -> -> ）を介してマージする必要があります。FI
RELEASEMAIN
RELEASEHOTFIXSERVICEPACKMAIN

アドバンスブランチプラン

最後のセクションでは、バージョンが本番環境にリリースされた後、マージのワークフローがどのように進むべきかについて明示的に言及していると思います。
新しい船用車両のセットを作成するために十分に統合されるまで、メインに戻る必要があります（新しいSPxを開始するバージョンを選択するサービスから、Hoyfix.spx、release.spxまで）

OP user1448758は、コメントの中で、製造上の欠陥をどこで修正すればよいかを指摘しています。言及している：

ブランチは、個別のブランチ構造ではなく、またはブランチのRelease子です。これにより、並行してサポートする必要のあるマイナーリリースまたはメジャーリリースごとに、複数のアクティブなリリースセット（パック、、ブランチで構成される）を使用できます。 ホットフィックスは、バグが見つかった特定のリリースに適用されてから、vNext開発ブランチにマージ（RI）され、場合によってはvNext開発ブランチにマージされます。hotfixservicingServiceHotfixRelease
Main

開発ブランチはリリースvNext後に作業を行っているため、開発ブランチの（リリース後）でvCurrent見つかった欠陥を修正することはお勧めしません。 リリース後、側面の欠陥（リリース後）を修正し、側面のSprint 2のバグ（プレリリース）を修正する必要があります（）。vCurrentvNext
Sprint 1Sprint 1releasedevelopmentvNext

Releaseの子ですhotfix。リリースを作成する時点では、リリースの内容hotfixとリリースは同じです。
Release読み取り専用になり、Hotfixリリースされたものに対して欠陥を修正するために使用できます。

構造を反転する際の問題は、を通過せずににhotfix移動できないことです。これを行うと、リリースされたコードのコピーがなくなりますMainRelease。

于 2012-09-15T22:02:19.590 に答える