2

私たちは、Rational ClearCase UCM モデルのストリーム構造を考え出しました。 

Int  
-- Prd  
-- Uat  
-- Dev  
---- Development Stream r1.0

最近、コード ベースを新しいセットアップに移行しました。3 つの異なるコード ベース、つまり 3 つの物理的なコード ベースがありました。

移行プロセス:

最初に本番コードを移動し、アクティビティを作成し、アクティビティを統合ストリームに配信し、ベースラインを作成しました。
次に、uat コードがアクティビティを作成し、そのアクティビティを統合ストリームに配信し、マージ中にコントリビューター 2 からの変更を選択して、uat の既存のコードを保持し、ベースラインを作成しました。開発環境の同じプロセス。

現在、統合ストリームには、開発ベースラインである最新のベースラインがあります。
これで、それぞれの環境でリリースが行われる prd と uat 用の他の 2 つのストリームができました。

私は今私の開発ストリームを持っています。アクティビティを作成し、いくつかの変更を加えます。ここで、これらの変更を uat 環境にプロモートする必要があります。インテグレーション ストリームに変更を配信すると、マージは完了しますが、開発ベースライン上で行われます。多くの開発アプリが望ましくない uat にリベースされるため、uat にリベースしたくありません。

uat 環境 (uat ストリーム) への変更を促進するにはどうすればよいですか。親切にアドバイス。

4

1 に答える 1

0

ストリーム構造は次のようになります。

Int
  Dev
  UAT
  Prd

インテグレーション ストリームに変更を配信すると、マージは完了しますが、開発ベースライン上で行われます。多くの開発アプリが望ましくない uat にリベースされるため、uat にリベースしたくありません。

ストリームの原則は、特定の開発作業を分離することです。

  • 開発者の日々の開発
  • UATの読み取り専用モードでテストします（何も触れないでください。テストして受け入れるか拒否するだけです）
  • Prd のホット フィックス

Int は最新の Prd ベースラインを記録して、別のプロジェクトがこれらのベースラインの 1 つを開始点として使用できるようにし、ブランチのブランチのブランチから作成されたベースラインの使用を回避します (「カスケード分岐」)。

私はお勧めします (これは 1 つの命題にすぎません。他から分離するために必要な開発作業の正確なセットに応じて、他の多くの構造が可能です):

Int
  Prd
  Dev
    UAT
  • テストしたい開発ベースラインで UAT をリベースします (そうすれば、開発者は、ユーザー受け入れテストのためにテストされているコンテンツをいじることなく、毎日の開発を続けることができます)。
  • ベースラインが UAT にリベースされている場合は、それを本番環境に直接配信します (直前にホットフィックスが発生する可能性があります)。
  • Prd ベースラインが設定されて安定したら、それを Int に配信します (これが本番環境で実行されているという事実を記録するため)。
于 2010-04-08T06:22:55.317 に答える