我的同事和我相对需要Clearcase UCM的流式创意。目前,管理层已经为每个功能软件包创建了流,每个功能软件包都定义了接口并位于分层体系结构中。开发人员根据他们正在工作的软件包创建子流,并尝试独立开发他们的代码,但是他们通常在初始开发期间依赖于其他软件包。这导致我们的集成小组创建了系统构建,然后开发人员使用这些系统构建一个适当的环境来开发他们的软件并手动引入依赖关系(即压缩文件,补丁等)。Clearcase UCM - 如何使用流和组件,如何?
我的观点是,这是错误的,并不是UCM如何使用,但我需要更熟悉UCM的人来确认我的信念。我认为应该从功能的角度创建流(每个包执行一些功能,多个架构包有助于实现某些客户功能,称之为“ABC”)。然后,将执行功能“ABC”的初始开发的每个架构组件的组件添加到流中。所有功能“ABC”的开发人员现在都可以在流中(或在某些子流中)完成该功能。完成后,每个UCM组件都有一个基准,并且从UCM的角度来看,组件之间不存在“绑定”(有人声称这可能由于活动记录而在UCM内部发生)。
注意:我同意也许你不以这种方式工作,但在最初的开发过程中,接口通常会发生变化,您尚未实现所有函数的所有接口,因此多个组件在一个流中一起工作最有意义。稍后,您可以转换到“架构软件包中心”的工作方式,其中每个软件包与另一个软件包中的更改无关。
想法?对于这篇长文章感到抱歉,我觉得细节是必要的。