clearcase UCM：在开发者流上提供基线

Question

我目前正在一个刚刚完成过渡到ClearCase UCM的大型项目中工作，我们的流树看起来像这样：

• Main_Int_Stream
  • Main_Dev_Stream
    • User_Dev_Stream
    • User_Dev_Stream
    • User_Dev_Stream
  • Main_Dev_Stream
    • User_Dev_Stream
    • User_Dev_Stream
    • User_Dev_Stream

这个模式在多个项目中重复，每个项目只有一个主要的int流和x个主要的dev流（通常是x <5）

我知道每个开发人员的一个流并不理想，但这个设计不在我手中，我需要让jenkins在这个流树下进行持续集成。

我的队友和我自己想出了这个设计：

有关此设计的几点说明：

1. Jenkins将有一个每3-5分钟运行一次的作业，可以检测用户开发流何时有新的基线（用户必须在其用户开发流上创建基线，然后由jenkins检测到，这是所有用户所做的，其他一切都是自动化的。

2. 詹金斯流将由jenkins创建为用户开发流的子流，它将基于检测到的基线。

   • Jenkins会使用此流进行rebase，然后构建基线，如果失败，则会拒绝基线（用户必须创建固定基线并重试）。
   • 如果构建成功，则会传递基线并建议基线，此时基线会被提升为交付。
   • 如果rebase导致合并冲突，用户将通过电子邮件收到通知，用户必须重新绑定并创建新基线以再次尝试（用户需要在其流上创建新基线之前进行重新绑定）。 / LI>

3. 一旦jenkins完成验证基线并根据构建结果采取行动，jenkins将删除它创建的流/视图以执行检查。 （詹金斯流是一个临时流，只有在詹金斯建造时才有效。）

4. Jenkins有一个每个组件的队列， 同一个组件的两个基线不会并行构建，基线在组件范围内完成 。

总结了拟议的设计，但由于以下原因，我们暂时关闭了：

1. 在用户开发流上创建基线是一个“糟糕的主意”，因为如果给定的文件被破坏，它就会产生“混乱”，因为它不会回溯。
2. 用户开发流上的基线太多会创建一个“无法管理”的依赖关系链，并且会花费“大量时间”来跟踪给定文件中给定的更改回原点。
3. 基本上，这种设计“不可持续”，因为从长远来看会产生大量的基线。

这是反对它的论点。但是我们指出，从用户开发流（即它当前的工作方式）进行交付会在流上创建deliverybl基线，因此基线的数量与此设计相比与其他设计相同。

然而，反驳的论点是：

“在交付表单流上由clearcase创建的deliverybl基线与用户创建的基线不同，并且它们是可管理的”

当询问基线之间有什么不同时，响应是：

“他们不同，相信我”

这让我想到了实际的问题：

1. 这种设计实际上是不可持续的（长期依赖链）？
2. 用户在其用户开发流上创建基线，然后将这些基线作为将更改从用户开发流移动到主开发分支的方法是否存在问题？
3. 用户创建的基线和deliverybl基线是否真的不同？如果是这样，他们有什么不同？并且可以向用户提供关于如何创建基线的要求，这些基线将使基线等同于deliverybl基线？
   • 如果它们不同，那么来自流设计的交付实际上与基线设计的交付有何不同，后者使后者不可持续？
4. 有关如何改进此设计的任何建议？

谢谢，我知道这是一篇很长的帖子，我很感谢你花时间阅读和回答我的问题。

干杯， Roy Bunting

Answer 1

  

这种设计实际上是不可持续的（长期依赖链）吗？

是的，因为您必须使用清除机制来清理旧的基线 并不总是可以使用rmbl，特别是如果该基线是交付的一部分。

  

用户在其用户开发流上创建基线，然后将这些基线作为将更改从用户开发流移动到主开发分支的方法是否存在问题？

原理是合理的，但实施（尽管ClearCase UCM提供）可能非常慢，具体取决于组件的大小。
并且可能存在订单问题，其他开发人员可能希望首先进行折扣，在交付之前验证他们的更改是否仍然有效（as shown here）

  

用户创建的基线和deliverybl基线是否真的不同？

是的，如“What is deliverbl in UCM ClearCase?”中所述 除了未标记之外，您无法轻松删除它们，因为它们具有超链接和特殊的UCM属性。