本番環境へのデプロイを行う場合、コードにラベルを付けるか、本番環境にあるコードのブランチを作成する必要がありますか?
5 に答える
TFS では、本番環境にリリースされる特定のバージョンを識別するラベルが付いたリリース ブランチを作成します。
これは、他のブランチがあることを意味します。次のことをお勧めします
- 3 つの主要なブランチ: Main、Develop、および Release。
- 現在の火に対する 1 つのホットフィックス ブランチ。
- 開発の中断を含む 0 から N の主要機能ブランチ。
詳細
- 主枝
- 最新の安定したビルドが含まれています
- リリースごとにタグ/ラベルを付ける
- ブランチの開発
- メインから分岐
- ほとんどの作業が行われる場所
- リリース前にメインにマージする
- リリースブランチ
- 次のいずれかから分岐します。
- 開発ブランチ
- または Main ブランチ (「安定」しているため、これの方がよい場合があります)
- バグ修正はここで行われます
- 修正がテストされてリリースされた後、
- 開発ブランチにマージ
- または Main ブランチにマージしてから、Develop に前方統合 (FI - 親から子へのマージ) します。
- 各リリースまたはバグ修正にタグ/ラベルを付ける
- 次のいずれかから分岐します。
- ホットフィックス ブランチ
- メインから分岐
- Main に再マージ
- 開発への前方統合マージ
- メインが「安定」したままになるようにするために使用されます
- 主な機能ブランチ
- 開発から分岐
- 開発に再統合
- 通常の開発パスを混乱させる可能性のある主要な機能に使用されます
参考文献:
- 別のスタック オーバーフローの質問:いつタグ ラベルを使用し、いつ分岐するか、特に Martin Woodward の回答
- ソース管理のハウツーby Eric Sink
- Vincent Driessen による
成功した Git 分岐モデル
- これには、分岐モデルの非常に優れたグラフィックが含まれています
理想的には、両方。
特定のリリースに何を提供したかを正確に把握できるように、ラベルを付けたいと思うでしょう。ただし、リリースされたものにマイナーなバグ修正を実行して新しいリリースを作成できるように、ブランチを作成することも必要になるでしょう。
実際には、次の 2 つの方法のいずれかでアプローチできます。
- 本番リリースごとに分岐する継続的な開発タイムラインを用意します。
例:
------------------------->dev
| | |
| | |
| | |
v1.0 v2.0 v3.0
- 本番リリースを互いに「カスケード」させます。
例:
---->v1.0---->v2.0---->v3.0
最終的に、どのアーキテクチャを採用するかは、一貫性があり、自分にとって意味があるものである限り、自分で決定する必要があります。
両方を組み合わせて使用できます。すべてのプロジェクトでこれを内部的に行う方法を次に示します。
マイナー バージョンとメジャー バージョンごとに、Branches フォルダとサブ フォルダを持つ構造になっています。また、個々のサブフォルダーに設定したラベルを使用して、将来いつでも特定のバージョンを簡単に再構築できるようにします。
$\Branches
\2012.01
\2012.02 (branched from 2012.01)
\2012.03 (branched from 2012.02)
\2013.01 (branched from 2012.03)
詳細については、Visual Studio Team Foundation Server Branching and Merging Guideも参照してください。
私は両方が行われているのを見てきました.ラベリングはより軽量で、私にとっては簡単です. ただし、ラベルはかなり簡単に削除できることが指摘されています。ブランチは、「破棄」されない限り実際には削除されないことで、これを防ぎます。ブランチを使用しないほうがよい理由は、ルートから最新のものを取得する傾向があり、それらすべてのブランチがハード ドライブをいっぱいにしたくないため、ブランチをクロークする必要がないからです。
記録のために、ラベルが削除されていると指摘されたので、これを軽減するために、管理者とビルド サービス アカウント以外の全員からラベル付けのアクセス許可を削除しました。