0

同時に複数のブランチ (リリース) をサポートする必要がある大規模なソフトウェア プロジェクトがあるとします。たとえば、Web サイト上の製品リリース、現在顧客によってテストされている統合テスト リリース、ローカル システム テスト用のテスト リリース、および開発者が新機能をハッキングする開発リリースがあります。

このセットアップを適切にサポートするバージョン管理システムはどれですか? 私の主な懸念は、異なるリリース間のマージをサポートする必要があるということです。本番リリースで緊急のバグを修正する場合、他のすべてのリリースもチェックアウトして手動でバグを 5 回修正したくありません。

回答がある場合は、それを適用したプロジェクトの規模と経験をお聞かせください。開発者によるマージを明示的にサポートするシステムを探しています。ビルド マネージャーなどによってスクリプトが適用されたソリューションは役に立ちません。(あまりにも危険です。マージは、開発者が何をすべきかを最もよく知っているため、開発者がすぐに実行する必要があります。)どうもありがとうございました!

4

7 に答える 7

1

本当に複数のリリースを処理したいが、Clearcase の苦痛に悩まされたくない場合は、AccurevPlasticSCMなどを試してください。

Accurev は、そのストリームを処理するのに非常に強力です。慣れる必要がありますが、慣れると非常に強力です。

Plastic は、無制限の数のブランチ (およびそれに対応するマージ) を処理するという点でより強力です。言うは易く行うは難しです。古き良き CC で言及されているすべての柔軟性がありますが、難解なコマンドや奇妙な構成はありません。

ここでは、ブランチ エクスプローラーが複数のブランチを追跡しています。

代替テキスト

于 2009-04-13T23:00:22.533 に答える
1

この質問に対する答えは、まずプロセス、次にツールチェーンです。

既知のバージョンにどのようにアクセスしたいか (たとえば、「本番環境は?」)、それらに変更を加えたい方法、および変更を他のバージョンに配布する方法を決定する必要があります。

Subversion-Or-Better であるほとんどの VCS システムは、一般的なワークフローをサポートします。一般的なものを次に示します。

  1. 開発はトランクにある
  2. リリースの時期になったら、トランクにタグを付けます (例: 1.3.0)
  3. 1.3.x など、作成したタグでトランクからブランチを作成します。
  4. 「タグ」に基づいてコードをリリースします (例: 1.3.0)
  5. トランクの新機能の開発を再開する
  6. 本番環境でバグを修正する必要がある場合は、ブランチをチェックアウトして修正してください。それを通常どおり解放し、新しいタグを作成します (例: 1.3.1)。
  7. 必要に応じてブランチからトランクに変更をマージします
  8. 次のリリースまで、必要に応じて手順 6 と 7 を繰り返します。

別の一般的な方法を次に示します。

  1. 開発はトランクにある
  2. リリースの時間になったら、トランクにタグを付けます
  3. 「タグ」に基づいて本番環境にリリース (例: 1.3.0)
  4. バグが見つかった場合は、タグに対してそのバグを修正するブランチを作成します
  5. 新しいブランチでコミットし、タグを付け直します (例: 1.3.1)
  6. そのブランチをトランクにマージします
  7. バグが見つかったら、手順 4、5、および 6 を繰り返します。

これらは非常に一般的で、実装/理解が簡単です。ほとんどのバージョン管理システムで簡単にサポートされます。より複雑なプロセスを取得すると、使用可能なツールセットが減少しますが、より強力になる可能性があります。

于 2009-04-15T22:34:34.717 に答える
1

Clearcaseは、複数のブランチとリビジョンを処理し、これらのいずれかまたはすべてをマージします。自由にブランチを定義し、必要に応じてラベルを付けて、これらとの間でマージできます。言うまでもなく、これは非常に複雑になる可能性があり、IBM はその手助けとなるマージ マネージャーを提供しています。ブランチをグラフィカルに表示できます (それが役立つ場合)。

Clearcase は驚くほど強力ですが、その分複雑で管理に時間がかかります。

于 2009-04-07T11:14:25.040 に答える
1

Team Foundation Server は、任意の数の分岐とマージをサポートします。このままでも十分に機能しますが、2010 リリースの機能により、分岐はさらに魅力的になります。10-4 エピソード 4: もう並列開発の痛みはありませんを参照してください。

于 2009-04-07T11:14:47.050 に答える
0

このようなセットアップをサポートするようにTelelogic CM Synergy/CMを構成することができます。

良い点は、それらのリリースでファイルが変更されていない場合、開発者またはビルド マネージャーのアクションなしで、すべての「上位」リリースが自動的に更新されることです。変更されたファイルが変更された場合、開発者はチェックイン時にすぐに通知され、それらをマージする必要があります。関連する変更をタスクと変更要求にグループ化することをサポートし、それらに関連付けられた追跡システムを備えています。

悪い点は、非常に大きくて遅いこと、 buildmanagerに多くの時間を必要とすること、そして Eclipse 統合がほとんど使用できないことです。おそらく、5 人から 10 人の開発者ごとにフルタイムのビルドマネージャーが必要になるでしょう。

于 2009-04-07T11:08:34.350 に答える