1

PROD_int から release_Int の子を持ち、次にメンテナンス/ホットフィックスの子と projectA_Int を含む 2 つの構造があります。projectA には deploy & dev と projectB_int の子があり、projectB には deploy & dev と projectC_int の子があり、ProjectC には子があります。 Deploy & dev の もう 1 つはメインラインで、Prod_int、maintenance_int、hotfix_int、projectA_int、および projectB_int がすべて同じダウンラインにあり、それぞれ (PROD を除く) にデプロイと開発の子ストリームがあります。しかし、後者の方がマージの競合が多いようです。それが構造なのか、それとも私たちがそれらを使用している方法なのかはわかりません

一方が他方より多くのマージを引き起こしますか?

4

1 に答える 1

1

だから基本的に：

PROD_Int
  |
  --Release_Int
    |
    --Maintenance_Int
      |
      --HotFix

ProjectA/B/C
  |
  --deploy
  |
  --dev

対。

Int
|
--Prd_Int
|
--maintenance_int
|
--hotfix_int
|
--ProjectA/B_Int

階段のシナリオで時間がかかるのは、配信/リベースのサイクルです。
ただし、サブストリームからコードを統合する必要がある場合は常に、親ストリームが役立ちます。
開発ライフサイクルのさまざまなステップを表現したいだけの場合、delivedr の人為的な必要性のために、親ストリームは有害です。その後、他のストリームにリベースします。

2 つの UCM プロジェクトを使用した混合アプローチをお勧めします。

  • 統合、製品、ホットフィックス専用の 1 つ、
  • 1つは開発専用です。

リリース日が近づくと、1 つの (開発) プロジェクトから統合へのデリバリングを開始してから、ストリーミングする機能を凍結し、リリース時に製品にリベースし、リリース後のメンテナンスのためにホットフィックスにリベースすることができます。

'deploy' と 'dev' を一緒に混ぜようとしないでください: それらはあまりうまくいきません。

  • Dev は、多くの機能サブストリームの親です。
  • Deploy can は「Integration」の子であり、実際に本番環境に移行するものを統合します。
于 2012-07-26T20:12:12.363 に答える