1

我们有两个结构，从 PROD_int 开始的阶梯是 release_Int 的子级，然后是维护/修补程序的子级以及 projectA_Int，projectA 有 deploy 和 dev 的子级以及 projectB_int，projectB 有 deploy 和 dev 的子级和 projectC_int，然后 ProjectC 有子级部署和开发。另一个是主线，其中 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

在阶梯场景中需要时间的是交付/重新设置周期。
但是每次您需要整合来自子流的代码时，父流很有用。
如果您只是想表示开发生命周期中的不同步骤，那么父流是有害的，因为人为需要交付，然后基于其他流重新定位。

我建议采用混合方法，包含 2 个 UCM 项目：

  • 一种致力于集成、产品和修补程序，
  • 一个致力于开发。

当发布日期临近时，您可以开始从一个（开发）项目交付到集成，然后冻结您的功能流，在发布时变基为 prod，然后基于修补程序变基以进行发布后维护。

不要试图将“部署”和“开发”混为一谈：它们的配合不太好。

  • Dev is parent for many feature substream.
  • Deploy can is the children of 'Integration', where you have consolidated what will actually goes into production.
于 2012-07-26T20:12:12.363 回答