我和我的同事相对需要使用 Clearcase UCM 的流创意。目前管理层已经为每个功能软件包创建了流，每个软件包都有定义的接口并存在于分层架构中。开发人员根据他们正在使用的包创建子流，并尝试独立开发他们的代码，但是他们通常在初始开发期间依赖于其他包。这导致我们的集成小组创建系统构建，然后开发人员使用这些构建来创建足够的环境来开发他们的软件并手动引入依赖项（即 zip 文件、补丁等）。
我的论点是这是错误的，而不是 UCM 的预期用途，但我需要更熟悉 UCM 的人来确认我的信念。
我认为应该从功能的角度创建流（虽然每个包都有一些功能，但多个架构包有助于实现一些客户功能，称之为“ABC”）。然后，将针对功能“ABC”执行初始开发的每个架构组件的组件添加到流中。现在，功能“ABC”的所有开发人员都在流（或某些子流集）中工作以完成该功能。一旦完成，您就有了每个 UCM 组件的基线，并且从 UCM 的角度来看，组件之间不存在“绑定”（有人声称这可能由于活动记录而在 UCM 内以某种方式发生）。
注意：我同意你可能不会永远这样工作，但是在接口通常发生变化的初始开发过程中，你还没有实现所有功能的所有接口，因此让多个组件在一个流中一起工作是最有意义的. 稍后，您可以过渡到“以架构包为中心”的工作方式，其中每个包都独立于另一个包的更改。
想法？抱歉发了这么长的帖子，我觉得细节是必要的。