2009-12-03 47 views
1

我的同事和我相对需要Clearcase UCM的流式创意。目前,管理层已经为每个功能软件包创建了流,每个功能软件包都定义了接口并位于分层体系结构中。开发人员根据他们正在工作的软件包创建子流,并尝试独立开发他们的代码,但是他们通常在初始开发期间依赖于其他软件包。这导致我们的集成小组创建了系统构建,然后开发人员使用这些系统构建一个适当的环境来开发他们的软件并手动引入依赖关系(即压缩文件,补丁等)。Clearcase UCM - 如何使用流和组件,如何?

我的观点是,这是错误的,并不是UCM如何使用,但我需要更熟悉UCM的人来确认我的信念。我认为应该从功能的角度创建流(每个包执行一些功能,多个架构包有助于实现某些客户功能,称之为“ABC”)。然后,将执行功能“ABC”的初始开发的每个架构组件的组件添加到流中。所有功能“ABC”的开发人员现在都可以在流中(或在某些子流中)完成该功能。完成后,每个UCM组件都有一个基准,并且从UCM的角度来看,组件之间不存在“绑定”(有人声称这可能由于活动记录而在UCM内部发生)。

注意:我同意也许你不以这种方式工作,但在最初的开发过程中,接口通常会发生变化,您尚未实现所有函数的所有接口,因此多个组件在一个流中一起工作最有意义。稍后,您可以转换到“架构软件包中心”的工作方式,其中每个软件包与另一个软件包中的更改无关。

想法?对于这篇长文章感到抱歉,我觉得细节是必要的。

回答

0
  • 每个功能软件包
  • 所有开发者功能“ABC”现在流中工作(或者在某些组子流)创建的流来完成该功能

是的,这几乎是流的两个UCM正常用法
(唯一非常不好的用法是涉及每个开发人员的一个流,仅用于隔离目的,这将是疯狂的,因为specified before

这两个模式是系统方法组件方法,在this answer详细。
基本上,您希望在开发的初始阶段避免过多的合并或重置,并在开始时保持一个连贯的系统(所有组件都是可写的)。
然后,当API稳定后,您可以为每个可写组件创建一个流。

注意:当您有一组定义好的基准引用所有组件的稳定状态(只读),并且您可以部署和测试的位置时,这并不妨碍您建立“系统集成”流你的系统。
这些流保存在一个或多个单独的“集成”UCM项目上。

0

我同意VonC。我更喜欢功能性的方法。

有一个ClearCase插件可以帮助您为您的用户(流,视图,项目策略)建立环境,无论采取何种方式。只是谷歌关于“clearEnv”