VSTS：ブランチとマージベスト開発アプローチ - QA - 生産

Question

ソース管理、CIおよびリリース管理にVSTSを使用しています 環境やブランチではなく、一度だけコードをビルドしようとしています。 リリースパイプライン： Dev - > QA - > PROD

私は、チームが変更をコミットするブランチまたはコードベースが1つしかありません。 CIは、修正のためのすべてのコードが準備できたらビルドを開始します。私は リリースを作成し、プロダクションに展開するまでパイプラインを通してそれを宣伝します。

1つのブランチがうまくいくかどうかを知る必要があるので、バグを修正したり、ブランチを作成してマスターブランチに毎日コミットするだけで新しい機能を作成したりする場合は、

環境ごとに3つのブランチを使用しないようにしようとしています。私は、CIとリリース管理が、以前のビルドからのリリースを作成する能力を私たちに提供すると考えています。

私の場合、両方のアプローチ（3つのブランチまたは1つのマスターブランチのみ）の短所と長所は何ですか？

Answer 1

通常、1つのリリースパイプラインに対して1つのブランチが必要です。 1つのパイプラインに複数の環境があるかもしれませんが、リリースパイプラインには、ビルド後にソフトウェアがどのように最終的にリリースされたかが反映されているため、それらに配布されるリリースは同じである必要があります。たとえば、リリースは最初にテストのためにQA環境にデプロイされ、QA環境のテストがパスされた後でのみ本番サーバーにデプロイできます。 QAが1つのブランチのビルドを使用し、Prodが別のブランチのビルドを使用することは意味がありません。詳細については、このリンクを参照してください：Where to deploy? Environments in Microsoft Release Management。

ブランチの場合は、開発プロセスです。

チームはいつブランチを追加する必要がありますか？

次のような状況でブランチを作成する必要があります

• あなたは 既存の支店とは異なるスケジュール/サイクルでコードを公開しなければならないとき。

• コードに異なる分岐ポリシーが必要な場合。新しいポリシーを持つ新しい ブランチを作成する場合は、 プロジェクトに戦略的価値を追加できます。

• 機能が顧客にリリースされ、チームが に計画している場合、計画されたリリースサイクルに影響を与えない変更を行います。

は高い統合コストを生成するため、ユーザーストーリーごとに分岐を作成しないでください。 Team Foundation Serverは の分岐を容易にしますが、ブランチが多数ある場合は、ブランチを管理するオーバーヘッドは になります。

詳細はこのリンクをチェックしてください：あなたはQAにあるリリースを持っているときBranch strategically

Answer 2

環境ごとにブランチを作成する必要はありませんが、開発プロセスに関するいくつかの質問をする必要があります。

どのくらいの頻度で新機能をリリースしますか？すべてのチェックインで完全に自動化され、実行される包括的なユニット、統合、回帰、ユーザー受け入れテストをお持ちですか？

新しい機能を開発していて、すばらしい自動テストのセットがない場合は、少なくとも1つ以上のブランチが必要になることがあります。新しい機能を開発するには1、ライブコードベースをサポートするには1。 ALM Rangers branching guidanceを読んでそこから行ってください。