社内アプリケーションのTFS 2010分岐モデル

Question

これは私がアイデアを持っていないという質問ではありませんが、代わりにモデルを提示して、承認されるか、誰かがそれについて問題を見ることができるか、より良い提案があるかを確認したいと思います。彼らは、将来の頭痛を回避するために、分岐モデルを慎重に選択する方が良いと言います。

したがって、顧客にリリースされたバージョン（最新）のみが1つのバージョンのみを備えた社内アプリケーションがあり、基本的には2種類の開発アクティビティがあります。主なアクティビティは次のリリースで機能しており、通常は新機能と修正修正が含まれています。計画されており、2番目のものは計画されておらず、メンテナンスに関するもので、現在のバージョンのホットフィックスが含まれています。

長い研究の後、私たちは一緒に行くことにしました 主要 2つの子枝を分岐するトランク： 発達 & メンテナンス （また hotfix）。ガイドに示されているように、毎日の開発は 発達 次のリリースの準備が整うたびに、リバース統合（RI）を行う場所からブランチがあります。リリースの直前に逆統合が停止し、コードが安定します 主要 ブランチ。からのリリース後 主要 からのフォワード統合（fi）があります 主要 に 発達 と メンテナンス.

ホットフィックスはで発生します メンテナンス 修正のみによってのみ（たとえば、コードベースに保持したい場合） 主要 そしてそこからfiが入ります 発達.

少なくとも紙の上では、すべてが大丈夫に見えるので、このモデルについて他の人の意見を聞きたいと思います。

たとえば、別のブランチがあることも検討します。 リリース, 、コードの安定化が生産へのリリースの前に発生する場所（直接作業する代わりに 主要）そしてもちろん、ここから生産のためにリリースし、RIに 主要 続いてfiが続きます 発達 & メンテナンス, 、しかし、これが何らかの利益をもたらすのか、それとも複雑さを高めるのかはわかりませんか？

そして、機能があると仮定します 発達 次のリリースの準備ができていないか、望ましくないことは、必要な機能に関連する変更セットの「チェリーピッキング」を行う必要があることを意味しますが、ドキュメントによるとそれほど良くありません。助言がありますか？

繰り返しますが、それは単純で簡単な質問ではなく、代わりにオープンな質問であることを知っていますが、同様の経験を持つ人から聞いてみたいと思っています。よろしくお願いします。

Answer 1

TFS Alm Rangers Branching Guidanceドキュメントを読みましたか？提案しているものは、「標準的なブランチプラン」によく似ていますが、リリースと「サービスパック」ブランチの両方を持つことを奨励しています（上記のリリースやメンテナンスブランチによく似ています）。

http://vsarbranchingguide.codeplex.com/

いくつかのクライアントに標準分岐計画を実装しましたが、問題はありませんでした。同時の作業ストリーム（機能クルーなど）を採用する予定がある場合、分岐ガイダンスにもそのための確かな計画があります。

考慮すべきもう1つのことは、各リリースで新しい開発ブランチを作成し、古いブランチをリリースとしてフリーズする階段ステップモデルかもしれません。必要に応じて、古いものをホットフィックスし、新しい開発ブランチの修正をFiすることができるため、これはRIを回避します。私もこのモデルで働いてきましたが、それは素晴らしかったです。