私のチームはついに SourceSafe から TFS 2010 に移行し、戦略を立てようとしています。
現在のサービス リリースに取り組んでいる間に、バグ修正を次のサービス リリースに反映できるようにする必要があります。基本的に、ある時点で、現在のリリースでのバグ修正を停止し (いくつかの重要なものを除く)、そのリリースを 1 ～ 2 週間パイロットします。この間もバグを修正したいと考えているため、次のサービス リリースに含めます。これは、次のメジャー リリースに向けた開発とは別のものです。
私たちは、サービス リリース ブランチをメインから、ホット フィックス ブランチをサービス リリースから、リリース ブランチをホット フィックスから切り離すことを含む、成熟したブランチ戦略の外観が気に入っています。次に行うことは、リリース ブランチを試験運用しているものとして保持し、サービス リリース ブランチにバグ修正を追加できるようにすることです。次に、パイロットを終了し、最後の重要な変更を行ったら、ホット フィックスおよびサービス リリース ブランチを介してリリース ブランチをメインにマージし、サービス リリース ブランチから新しいホット フィックスおよびリリース ブランチを作成します。次のサービス リリースになります。
これに関する大きな問題は、メインに入るすべてのものを完全にテストしたいということです。リリース ブランチはそのままですが、メインにマージし直すと、ホット フィックスおよびサービス リリース ブランチにチェックインしたすべての変更が反映されます。これらの変更は、現時点ではテストされていません。
これを回避するために、リリースがメインにマージされるまで、開発者がサービス リリース ブランチでの変更を棚上げすることを計画しています。これは私にとって最良のアイデアとは思えませんが、これを処理するために他に何も考えられません。
他の誰かが同様のことをしなければならず、これを処理するより良い方法がありましたか?